draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-09.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: June 14, 2011 T. VanCaenegem Expires: June 17, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
December 11, 2010 December 14, 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-08 draft-ietf-avt-ports-for-ucast-mcast-rtp-09
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 attacks that solution provides protection against denial-of-service or packet
could be used to cause one or more RTP packets to be sent to a victim amplification attacks that could be used to cause one or more RTP
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 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 June 14, 2011. This Internet-Draft will expire on June 17, 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 13
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 . . . . . . . . . . . . . . . . . . . . 5
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6
3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 6 3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 6
3.2. Unicast Session Establishment . . . . . . . . . . . . . . 6 3.2. Normative Behavior and Requirements . . . . . . . . . . . 9
3.2.1. Motivating Scenario . . . . . . . . . . . . . . . . . 6 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Normative Behavior and Requirements . . . . . . . . . 9 4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13
4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 11 4.3. Token Verification Request . . . . . . . . . . . . . . . . 15
4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 12 4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16
4.3. Token Verification Request . . . . . . . . . . . . . . . . 14 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 16
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 15 5. Procedures for Token Construction . . . . . . . . . . . . . . 18
5. Procedures for Token Construction . . . . . . . . . . . . . . 17 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 20
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 19 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 21
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 21
7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 20 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 22
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 21 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 25
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 26
9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 28
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 27 10.2. Registration of RTCP Control Packet Types . . . . . . . . 28
10.2. Registration of RTCP Control Packet Types . . . . . . . . 27 10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 28
10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 27 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 29
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
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. 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 Translators (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 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
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Token-Based Port Mapping 3. Token-Based Port Mapping
Token-based Port Mapping consists of two steps: (i) Token request Token-based Port Mapping consists of two steps: (i) Token request
and retrieval, and (ii) unicast session establishment. These are and retrieval, and (ii) unicast session establishment.
described below.
3.1. Token Request and Retrieval
This first step is required to be completed only once. Once a Token The 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 and algorithm used to servers are provided with the same secret key and algorithm used to
generate the Token and are at least loosely clock-synchronized. The generate the Token and are at least loosely clock-synchronized.
Token becomes invalid if client's public IP address changes or when
the server expires the Token. In these cases, the client has to
request a new Token.
The Token is essentially an opaque encapsulation that is based on The Token is essentially an opaque encapsulation that is based on
client's IP address (as seen by the server). When a request is client's IP address (as seen by the server). When a Token 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. The Token becomes invalid if client's
establish a unicast session, the Token will be validated by the IP address (as seen by the server) changes (note that the client
server, making sure that the IP address information matches. This is cannot necessarily detect this in a timely manner) or when the server
effective against DoS attacks, e.g., an attacker cannot simply spoof expires the Token. In these cases, the client has to request a new
another client's IP address and start a unicast transmission towards Token.
random clients.
3.2. Unicast Session Establishment As the second step, when the client wants to establish a unicast
session, the client includes the Token with its RTCP feedback
message. The server validates the Token, making sure that the IP
address information matches. This is effective against DoS attacks,
e.g., an attacker cannot simply spoof another client's IP address and
start a unicast transmission towards random clients. If the
validation passes, the unicast session gets established. Otherwise,
the server notifies the client that the validation has failed, and in
this case, the unicast session will not be established.
The second step is the unicast session establishment. We illustrate Upon successfull validation and once the unicast session is
this step with an example. First, we describe the motivation established, all the RTP and RTCP rules specified in [RFC3550] and
scenario and then define the normative behavior and requirements. other relevant specifications also apply in this session until it is
terminated. During its lifetime, certain actions and messages by the
client might need to be authorized by the server by requiring a valid
Token. These are explained later in this document.
3.2.1. Motivating Scenario Below, we first present a motivating scenario for port mapping and
then describe the normative behavior and requirements.
3.1. Motivating Scenario
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 [RFC4588].
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, there can be sketched in Figure 2. Between the client and server, there can be
one or more NAT devices [RFC4787]. one or more NAT devices [RFC4787]. The multicast and unicast
sessions are clearly identified with their individual RTP and RTCP
flows and port numbers.
-------------- --- ---------- -------------- --- ----------
| |-------------------------------| |-->|P1 | | |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | | | | | | | |
| Distribution | ---------------- | | | | | Distribution | ---------------- | | | |
| Source | | | | | | | | Source | | | | | | |
| |---->|P1 | | | | | | |---->|P1 | | | | |
| |.-.->|P2 | | | | | | |.-.->|P2 | | | | |
| | | | | | | | | | | | | | | |
-------------- | P3|<.=.=.=.| |=.=|*c0 | -------------- | P3|<.=.=.=.| |=.=|*c0 |
| P3|<~~~~~~~| |~~~|*c1 | | P3|<~~~~~~~| |~~~|*c1 |
MULTICAST RTP | | | | | | MULTICAST RTP | | | | | |
SESSION with | | | | | | SESSION with | | | N | | |
UNICAST FEEDBACK | | | N | | | UNICAST FEEDBACK | | | A | | |
| Retransmission | | A | | Client | | Retransmission | | T | | Client |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| Server | | T | | | | Server | | | | |
| | | | | | | | | | | |
PORT MAPPING | PT|<~~~~~~~| |~~>|*cT | PORT MAPPING | PT|<~~~~~~~| |~~>|*cT |
| | | | | | | | | | | |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|- - - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| | | | | | | | | | | |
AUXILIARY UNICAST | | | | | | AUXILIARY UNICAST | | | | | |
RTP SESSION | | | | | | RTP SESSION | | | | | |
| P3|........| |..>|*c1 | | P3|........| |..>|*c1 |
| P3|=.=.=.=.| |=.>|*c1 | | P3|=.=.=.=.| |=.>|*c1 |
| P4|<.=.=.=.| |=.=|*c2 | | P4|<.=.=.=.| |=.=|*c2 |
skipping to change at page 9, line 5 skipping to change at page 9, line 49
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.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. example, and can be applied to any scenario where analogous ports can
be identified.
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)
when it is needed. That is, clients MUST NOT implement this
specification with only a specific use case in mind.
Second, the solution provided in this specification is not applicable
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
traffic MUST be only from the server to the client in the unicast
session. If the client wants to send RTP traffic back to the server,
the regular session establishment methods such as [RFC3264] need to
be used.
The following steps summarize the Token-based solution: The following steps summarize the Token-based solution:
1. The client ascertains server address and port numbers (P3, P4 and 1. The client ascertains server address and port numbers (P3, P4 and
PT) from the session description. Port P4 MUST be different from PT) from the session description. Port P4 MUST be different from
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.
skipping to change at page 9, line 39 skipping to change at page 10, line 48
easy), a client SHOULD use separate receive ports for subsequent easy), a client SHOULD use separate receive ports for subsequent
unicast sessions. After a sufficient time, a previously used unicast sessions. After a sufficient time, a previously used
receive port could be used again. receive port could be used again.
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 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 from the received message. learns client's IP address from the received message. The
The client can send this message anytime it wants (e.g., client can send this message anytime it wants (e.g., during
during initialization), and does not normally ever need to initialization), and does not normally ever need to re-send
re-send this message (See Section 6). 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 client's IP Token) based on certain information including client's IP
address. address.
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 needs to provide the Token to the server using a new 4. The client needs to provide the Token to the server using a new
RTCP message, called Token Verification Request, whenever the RTCP message, called Token Verification Request, whenever the
client sends an RTCP feedback message for triggering or client sends an RTCP feedback message for triggering or
controlling a unicast session (See Section 4.3). Note that the controlling a unicast session (See Section 4.3.1). If the Token
unicast session is only established after the server has received is invalid or missing, the server sends a new RTCP message,
a feedback message (along with a valid Token) from the client for called Token Verification Failure, to the client.
which it needs to react by sending unicast data. Until a unicast
session is established, neither the server nor the client needs Note that the unicast session is only established after the
to send RTCP reports for the unicast session. server has received a feedback message (along with a valid Token)
from the client for which it needs to react by sending unicast
data. Until a unicast session is established, neither the server
nor the client needs 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, traffic from the server to the client (i.e., unicast session, traffic from the server to the client (i.e.,
both the RTP and RTCP packets sent from port P3 to port c1) MUST both the RTP and RTCP packets sent from port P3 to port c1) MUST
be multiplexed on the (same) port c1. If the client uses the be multiplexed on the (same) port c1. If the client uses the
same port for both c0 and c1, the RTCP reports sent for the same port for both c0 and c1, the RTCP reports sent for the
multicast session keep the P3->c1(=c0) binding alive. If the multicast session keep the P3->c1(=c0) binding alive. If the
client uses different ports for c0 and c1, the client needs to client uses different ports for c0 and c1, the client needs to
periodically send an explicit keep-alive message periodically send an explicit keep-alive message
[I-D.ietf-avt-app-rtp-keepalive] to keep the P3->c1 binding alive [I-D.ietf-avt-app-rtp-keepalive] to keep the P3->c1 binding alive
skipping to change at page 12, line 21 skipping to change at page 13, line 21
|V=2|P| SMT=1 | PT=TOKEN=210 | Length=3 | |V=2|P| SMT=1 | PT=TOKEN=210 | 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): Mandatory field that contains a random o Random Nonce (64 bits): Field that contains a random nonce value
nonce value generated by the client following the procedures of generated by the client following the procedures of [RFC4086].
[RFC4086]. This nonce is taken into account by the server when This nonce is taken into account by the server when generating a
generating a Token for the client to enable better security for Token for the client to enable better security for clients that
clients that share the same IP address. If the Port Mapping share the same IP address. If the Port Mapping Request message is
Request message is transmitted multiple times for redundancy transmitted multiple times for redundancy reasons, the random
reasons, the random nonce value MUST remain the same in these nonce value MUST remain the same in these duplicated messages.
duplicated messages. However, the client MUST generate a new However, the client MUST generate a new random nonce for every 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 SSRC is set to the server's SSRC.
The packet format has the structure depicted in Figure 4. The packet format has the structure depicted in Figure 4.
0 1 2 3 0 1 2 3
skipping to change at page 13, line 27 skipping to change at page 14, line 27
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute | | Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time | | Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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): Mandatory field that o SSRC of Requesting Client (32 bits): Field that contains the SSRC
contains the SSRC of the client who sent the request. of the client who sent the request.
o Associated Nonce (64 bits): Mandatory field that contains the o Associated Nonce (64 bits): Field that contains the nonce
nonce received in the Port Mapping Request message and used in received in the Port Mapping Request message and used in Token
Token construction. construction.
o Token Element (Variable size): Mandatory element that is used to o Token Element (Variable size): Element that is used to carry the
carry the Token generated by the server. This element is a Token generated by the server. This element is a 32-bit aligned
Length-Value element. The Length field, which is 8 bits, Length-Value element. The Length field, which is 8 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. The Value field carries the Token (or more the Length field. This length does not include any padding that
accurately, the output of the encoding process on the server). is required for alignment. The Value field carries the Token (or
more accurately, 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 padded to the boundary using further bits
set to zero.
o Absolute Expiration Time (64 bits): Mandatory field that contains o Absolute Expiration Time (64 bits): Field that contains the
the absolute expiration time of the Token. The absolute absolute expiration time of the Token. The absolute expiration
expiration time is expressed as a Network Time Protocol (NTP) time is expressed as a Network Time Protocol (NTP) timestamp value
timestamp value in seconds since year 1900 [RFC5905]. The client in seconds since year 1900 [RFC5905]. The client does not need to
does not need to use this element directly, thus, does not need to use this element directly, thus, does not need to synchronize its
synchronize its clock with the server. However, the client needs clock with the server. However, the client needs to send this
to send this element back to the server along with the associated element back to the server along with the associated nonce in the
nonce in the Token Verification Request message, thus, needs to Token Verification Request message, thus, needs to keep it
keep it associated with the Token. associated with the Token.
o Relative Expiration Time (32 bits): Mandatory field that contains o Relative Expiration Time (32 bits): Field that contains the
the relative expiration time of the Token. The relative relative expiration time of the Token. The relative expiration
expiration time is expressed in seconds from the time the Token time is expressed in seconds from the time the Token was
was generated. A relative expiration time of zero indicates that generated. A relative expiration time of zero indicates that the
the accompanying Token is not valid. 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.
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. would trigger a new or control an existing unicast session. For a
Currently, the following RTCP messages are REQUIRED to be accompanied list of such messages, see Section 4.3.1.
by a Token Verification Request message:
o Messages that trigger a new unicast session:
* NACK messages [RFC4585]
* 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 packet sender SSRC is In the Token Verification Request message, the packet sender SSRC is
set to the client's SSRC. The client MUST NOT send a Token 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 5. packet format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=3 | PT=TOKEN=210 | Length | |V=2|P| SMT=3 | PT=TOKEN=210 | Length |
skipping to change at page 15, line 23 skipping to change at page 15, line 46
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute | | Associated Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packet format for the Token Verification Request message Figure 5: Packet format for the Token Verification Request message
o Associated Nonce (64 bits): Mandatory field that contains the o Associated Nonce (64 bits): Field that contains the nonce
nonce associated with the Token above. associated with the Token above.
o Token Element (Variable size): Mandatory Token element that was o Token Element (Variable size): Token element that was previously
previously received in the Port Mapping Response message. received in the Port Mapping Response message.
o Associated Absolute Expiration Time (64 bits): Mandatory field o Associated Absolute Expiration Time (64 bits): Field that
that contains the absolute expiration time associated with the contains the absolute expiration time associated with the Token
Token above. above.
4.3.1. Where to Include Token
The following RTCP messages are REQUIRED to be accompanied by a Token
Verification Request message when the Token capability is declared in
the session description:
o Messages that trigger a new unicast session:
* NACK messages [RFC4585]
* 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]
A server might determine that other RTCP messages also need to be
authenticated using the mechanism described in this document. Thus,
clients need to support including a Token with any necessary RTCP
message (See Section 3.2).
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.
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. In Request message in the RTCP packet although it was supposed to. In
the Token Verification Failure message, the packet sender SSRC is set the Token Verification Failure message, the packet sender SSRC is set
to the server's SSRC. The packet format has the structure depicted to the server's SSRC. The packet format has the structure depicted
in Figure 6. 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=4 | PT=TOKEN=210 | Length=4 | |V=2|P| SMT=4 | PT=TOKEN=210 | Length=5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client | | SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT of Request | Req. FMT| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | | Associated |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packet format for the Token Verification Failure message Figure 6: Packet format for the Token Verification Failure message
o SSRC of Requesting Client (32 bits): Mandatory field that o SSRC of Requesting Client (32 bits): Field that contains the SSRC
contains the SSRC of the client who sent the verification request. of the client who sent the verification request.
o Associated Nonce (64 bits): Mandatory field that contains the o PT of Request (8 bits): Field that indicates the type of the RTCP
nonce received in the Token Verification Request message. If packet that caused this failure message.
there was no Token Verification Request message included by the
client, this field is set to 0. o Req. FMT (5 bits): Field that indicates the feedback message type
(FMT) value of the RTCP packet that caused this failure. Together
with the field above, the client can infer which RTCP message it
has previously sent caused this failure message to be sent by the
server. For example, if the client did not include a valid Token
with an RTCP NACK message, the PT of Request field will indicate
205 (RTPFB) and the Req. FMT field will indicate 1 (Generic NACK).
If the RTCP message did not have an associated FMT value (such as
an RTCP BYE message), the Req. FMT field SHALL be set to zero.
o Associated Nonce (64 bits): 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.
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)
skipping to change at page 19, line 11 skipping to change at page 20, line 11
Finally, be aware that NTP timestamps will wrap around in year 2036 Finally, be aware that NTP timestamps will wrap around in year 2036
and implementations might need to handle this eventually. Refer to and implementations might need to handle this eventually. Refer to
Section 6 of [RFC5905] for further details. Section 6 of [RFC5905] for further details.
6. Validating Tokens 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 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 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
skipping to change at page 20, line 11 skipping to change at page 21, line 11
4xx-level response code in the RAMS Response Code Space Registry. A 4xx-level response code in the RAMS Response Code Space Registry. A
client that received a Token Verification Failure message can request client that received a Token Verification Failure message can request
a new Token from the server. a new Token from the server.
7. SDP Signaling 7. SDP Signaling
7.1. The portmapping-req Attribute 7.1. The portmapping-req Attribute
This new SDP attribute is used declaratively to indicate the port and This new SDP attribute is used declaratively to indicate the port and
optionally the address for obtaining a Token. Its presence indicates optionally the address for obtaining a Token. Its presence indicates
that (i) a Token MUST be included in the feedback messages sent to that (i) a Token MUST be included in certain feedback messages sent
the server triggering or controlling a unicast session (See to the server triggering or controlling a unicast session (The list
Section 4.3 for details), and (ii) the client MUST receive the of those feedback messages is in Section 4.3.1), and (ii) the client
unicast session's RTP and RTCP packets from the server on the port MUST receive the unicast session's RTP and RTCP packets from the
from which it sent the RTCP message triggering or controlling the server on the port from which it sent the RTCP message triggering or
unicast session. controlling the unicast session.
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-attribute = "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]. The 'portmapping- defined as specified in Section 9 of [RFC4566]. The 'portmapping-
req' attribute is used as a session-level or media-level attribute. req' attribute SHALL be used as a media-level attribute.
If used at a media level, the attribute MUST be used in a unicast
media block.
Note: This does not imply that Token Verification Request Note: This does not imply that Token Verification Request
messages need to be sent in the unicast session. Token messages need to be sent in the unicast session. Token
Verification Request messages accompany RTCP messages that trigger Verification Request messages accompany RTCP messages that trigger
or control this unicast session, and are sent either in the or control this unicast session, and are sent either in the
multicast session or the unicast session, depending on the RTCP multicast session or the unicast session, depending on the RTCP
message (See Section 4.3). message (See Section 4.3.1).
In the optional address value, only unicast addresses are allowed; In the optional address value, only unicast addresses SHOULD be used
multicast addresses SHOULD NOT be used without 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 corresponding to the unicast media stream is implied. "c" line corresponding to the unicast media stream is implied.
When using this SDP attribute in SDP offer/answer [RFC3264], the When using this attribute in SDP offer/answer exchanges [RFC3264],
following needs to be considered. This attribute is used the following needs to be considered. First of all, this attribute
declaratively. If included at session level, this applies to all is used declaratively, and there are no offer/answer exchanges
media lines that uses RTP. If included at media level, it applies to between the client consuming the SDP description and the actual
the RTCP feedback messages declared by this media block. server providing the service. At media level, this applies to the
RTCP feedback messages declared by this media block.
An offerer that desires the answerer to use Tokens in any RTCP An offerer that desires the answerer to use Tokens in RTCP messages
message sent to the offerer, i.e., received by the offerer, the sent to the server, i.e., received by the server, the attribute is
attribute is included. In case an offerer desires to declare support included. In case an offerer desires to declare support for using
for using Tokens as defined in this specification but do not need Tokens as defined in this specification but do not need Tokens to be
Tokens to be included for any RTCP messages to be received by the included for any RTCP messages to be received by the server, it can
offerer, it can include the 'portmapping-req' attribute without any include the 'portmapping-req' attribute without any parameters,
parameters, neither port nor address, either at a session or media neither port nor address.
level.
An answerer receiving an SDP offer with the "a=portmapping-req" line An answerer receiving an SDP offer with the "a=portmapping-req" line
with a port number SHALL use that port number and the address, either with a port number SHALL use that port number and the address, either
explicitly provided in the attribute or implicitly provided by the explicitly provided in the attribute or implicitly provided by the
"c" line, for any needed Token request. If the "a=portmapping-req" "c" line, for any needed Token request. If the "a=portmapping-req"
line attribute does not contain a port, the answer SHALL take note of line attribute does not contain a port, the answer SHALL take note of
the capability. the capability.
When sending an answer, if the 'portmapping-req' attribute has been When sending an answer, if the 'portmapping-req' attribute has been
present in the offer including a port number and the answerer present in the offer including a port number and the answerer
skipping to change at page 21, line 36 skipping to change at page 22, line 34
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 the
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/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 o Multiplexing RTP and RTCP on a single port on both endpoints in
the unicast session [RFC5761] 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
skipping to change at page 23, line 11 skipping to change at page 24, line 11
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). Since there is Request message needs to be sent to port 30000 (PT). Since there is
no address indiciated in this line, the client needs to retrieve the no address indicated in this line, the client needs to send the Token
Token from the address specified in the "c" line. request to the address specified in the "c" line.
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
skipping to change at page 25, line 10 skipping to change at page 26, line 10
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 denial-of-service (DoS) expiration date, provides protection against off-path denial-of-
attacks. An attacker using a certain IP address cannot cause one or service (DoS) attacks. An attacker using a certain IP address cannot
more RTP packets to be sent to a victim client who has a different IP cause one or more RTP packets to be sent to a victim client who has a
address. However, if the attacker acquires a valid Token for a different IP address. However, if the attacker acquires a valid
victim and can spoof the victim's source address, this approach Token for a victim and can spoof the victim's source address, this
becomes vulnerable to replay attacks. This is especially easy if the approach becomes vulnerable to replay attacks. This is especially
attacker and victim are behind a large-scale NAT and share the same easy if the attacker and victim are behind a large-scale NAT and
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 to enable network ingress filtering
[RFC2827] or not. If ingress filtering is enabled on a network, an [RFC2827] or not. If ingress filtering is enabled on a network, an
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
skipping to change at page 27, line 24 skipping to change at page 28, line 24
the number of this document prior to publication as an RFC. 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 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: 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
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 of the following value to the RTCP Control Packet types sub-registry of
the Real-Time Transport Protocol (RTP) Parameters registry: the Real-Time Transport Protocol (RTP) Parameters registry:
Value Abbrev. Name Reference Value Abbrev. Name Reference
-------- --------- --------------------------------------- --------- -------- --------- --------------------------------------- ---------
210 TOKEN Port Mapping [RFCXXXX] 210 TOKEN Port Mapping [RFCXXXX]
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 Specification Required is to be managed by the IANA according to the IETF Review policy of
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 [RFCXXXX]
1 Port Mapping Request [RFCXXXX] 1 Port Mapping Request [RFCXXXX]
2 Port Mapping Response [RFCXXXX] 2 Port Mapping Response [RFCXXXX]
3 Token Verification Request [RFCXXXX] 3 Token Verification Request [RFCXXXX]
4 Token Verification Failure [RFCXXXX] 4 Token Verification Failure [RFCXXXX]
5-30 Assignable - Specification Required 5-30 Unassigned IETF Review
31 Reserved [RFCXXXX] 31 Reserved [RFCXXXX]
The SMT values 0 and 31 are reserved for future use. The SMT values 0 and 31 are reserved for future use.
Any registration for an unassigned SMT value needs to contain the
following information:
o Contact information of the one doing the registration, including
at least name and email.
o A detailed description of what the new SMT represents and how it
shall be interpreted.
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 [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
skipping to change at page 30, line 42 skipping to change at page 31, line 42
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[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.
[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 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
12.2. Informative References 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,
 End of changes. 53 change blocks. 
207 lines changed or deleted 238 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/