draft-ietf-avt-ports-for-ucast-mcast-rtp-09.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-10.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 17, 2011 T. VanCaenegem Expires: June 23, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
December 14, 2010 December 20, 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-09 draft-ietf-avt-ports-for-ucast-mcast-rtp-10
Abstract Abstract
This document presents a port mapping solution that allows RTP This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services. The in RTP applications using both unicast and multicast services. The
solution provides protection against denial-of-service or packet solution provides protection against denial-of-service or packet
amplification attacks that could be used to cause one or more RTP amplification attacks that could be used to cause one or more RTP
packets to be sent to a victim client. packets to be sent to a victim client.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 17, 2011. This Internet-Draft will expire on June 23, 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. Motivating Scenario . . . . . . . . . . . . . . . . . . . 6 3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 7
3.2. Normative Behavior and Requirements . . . . . . . . . . . 9 3.2. Normative Behavior and Requirements . . . . . . . . . . . 9
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12 4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12
4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13 4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13
4.3. Token Verification Request . . . . . . . . . . . . . . . . 15 4.3. Token Verification Request . . . . . . . . . . . . . . . . 15
4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16 4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 16 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 17
5. Procedures for Token Construction . . . . . . . . . . . . . . 18 5. Procedures for Token Construction . . . . . . . . . . . . . . 19
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 20 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 21
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 21 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 21 7.1. The portmapping and portmapping-req Attributes . . . . . . 22
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22 7.1.1. ABNF Definition of portmapping . . . . . . . . . . . . 22
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 22 7.1.2. ABNF Definition of portmapping-req . . . . . . . . . . 22
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 25 7.1.3. Offer/Answer Model Considerations . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 24
9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 26 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 28 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.2. Registration of RTCP Control Packet Types . . . . . . . . 28 9.2. The portmapping and portmapping-req Attributes . . . . . . 28
10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 29 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 29
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 10.2. Registration of RTCP Control Packet Types . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . . 31 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
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
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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
that we refer to as Port Mapping. This solution allows receivers to that we refer to as Port Mapping. This solution allows receivers to
choose their desired UDP ports for RTP and RTCP in every unicast choose their desired UDP ports for RTP and RTCP in every unicast
session when they are running RTP applications using both unicast and session when they are running RTP applications using both unicast and
multicast services, and offer/answer exchange is not available. This multicast services, and offer/answer exchange is not available. The
solution includes a Token-based protection mechanism against denial-
of-service (DoS) or packet amplification attacks that could be used
to cause one or more RTP packets to be sent to a victim client. This
solution is not applicable in cases where TCP is used as the solution is not applicable in cases where TCP is used as the
transport protocol in the unicast sessions. For such scenarios, transport protocol in the unicast sessions. For such scenarios,
refer to [RFC4145]. refer to [RFC4145].
----------- -----------
| Unicast |................ | Unicast |................
| Source |............. : | Source |............. :
| (Server) | : : | (Server) | : :
----------- : : ----------- : :
v v v v
skipping to change at page 4, line 34 skipping to change at page 4, line 37
----------- -----------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 1: RTP applications simultaneously using both unicast and Figure 1: RTP applications simultaneously using both unicast and
multicast services multicast services
In the remainder of this document, we refer to the RTP endpoints that In the remainder of this document, we refer to the RTP endpoints that
serve other RTP endpoints over a unicast session as the Servers. The serve other RTP endpoints over a unicast session as the Servers. The
receiving RTP endpoints are referred to as Clients. receiving RTP endpoints are referred to as Clients. This terminology
also reflects the fact that when port mapping is used, the RTP
packets can only flow in one direction (from the server to the
client) in the unicast sessions.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "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. and retrieval, and (ii) unicast session establishment.
The first step is required to be completed only once. Once a Token Once a Token is retrieved from a particular server, it can be used
is retrieved from a particular server, it can be used for all the for all the unicast sessions the client will be running with this
unicast sessions the client will be running with this particular particular server till the Token expires. By default, Tokens are
server. By default, Tokens are server specific. However, the client server specific. However, the client can use the same Token to
can use the same Token to communicate with different servers if these communicate with different servers if these servers are provided with
servers are provided with the same secret key and algorithm used to the same secret key and algorithm used to generate the Token and are
generate the Token and are at least loosely clock-synchronized. at least loosely clock-synchronized.
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 Token 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. The Token becomes invalid if client's sends it back to the client. The Token becomes invalid if client's
IP address (as seen by the server) changes (note that the client IP address (as seen by the server) changes (note that the client
cannot necessarily detect this in a timely manner) or when the server cannot necessarily detect this in a timely manner) or when the server
expires the Token. In these cases, the client has to request a new expires the Token. In these cases, the client has to request a new
Token. Token.
As the second step, when the client wants to establish a unicast As the second step, when the client wants to establish a unicast
session, the client includes the Token with its RTCP feedback session, the client includes the Token with its RTCP feedback
message. The server validates the Token, making sure that the IP message. The server validates the Token, making sure that the IP
address information matches. This is effective against DoS attacks, address information matches. This is effective against DoS attacks,
e.g., an attacker cannot simply spoof another client's IP address and e.g., an attacker cannot simply spoof another client's IP address and
start a unicast transmission towards random clients. If the start a unicast transmission towards random clients. If the
validation passes, the unicast session gets established. Otherwise, validation passes, the unicast session gets established. Otherwise,
the server notifies the client that the validation has failed, and in the server notifies the client that the validation has failed, and in
this case, the unicast session will not be established. this case, the unicast session will not be established.
Upon successfull validation and once the unicast session is Upon successful validation and once the unicast session is
established, all the RTP and RTCP rules specified in [RFC3550] and established, all the RTP and RTCP rules specified in [RFC3550] and
other relevant specifications also apply in this session until it is other relevant specifications also apply in this session until it is
terminated. During its lifetime, certain actions and messages by the terminated. During the unicast session lifetime, certain actions and
client might need to be authorized by the server by requiring a valid messages by the client might need to be authorized by the server by
Token. These are explained later in this document. requiring a valid Token. Therefore, the server will need the client
to also include the Token along with the RTCP messages that are
different from the RTCP message that triggerred the unicast session
establishment. These are explained later in this document.
Below, we first present a motivating scenario for port mapping and Below, we first present a motivating scenario for port mapping and
then describe the normative behavior and requirements. then describe the normative behavior and requirements.
3.1. Motivating Scenario 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, we assume there
one or more NAT devices [RFC4787]. The multicast and unicast exists at least one NAT device [RFC4787] (If there is no NAT devices
sessions are clearly identified with their individual RTP and RTCP between the server and client, the method still works the same
flows and port numbers. fashion). 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 | | | | |
| | | | | | | | | | | | | | | |
skipping to change at page 10, line 32 skipping to change at page 10, line 32
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.
A client cannot keep using the same receive port for different
unicast sessions since there could be packet leakage when
switching from one unicast session to another unless each
received unicast stream has its own distinct Synchronization
Source (SSRC) identifier to allow the client to filter out the
undesired packets. Unless this is guaranteed (which is not often
easy), a client SHOULD use separate receive ports for subsequent
unicast sessions. After a sufficient time, a previously used
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 Port Mapping Request message
message, called Port Mapping Request to port PT. This (Section 4.1) to port PT. This message is sent from port *cT
message is sent from port *cT on the client side. The server on the client side. The server learns client's IP address
learns client's IP address from the received message. The from the received message. The client can send this message
client can send this message anytime it wants (e.g., during anytime it wants (e.g., during initialization), and does not
initialization), and does not normally ever need to re-send normally ever need to 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 the 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 Port
RTCP message, called Port Mapping Response. This message Mapping Response message (Section 4.2). This message MUST be
MUST be sent from port PT to port cT. 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 Token
RTCP message, called Token Verification Request, whenever the Verification Request message (Section 4.3), whenever the client
client sends an RTCP feedback message for triggering or sends an RTCP feedback message for triggering or controlling a
controlling a unicast session (See Section 4.3.1). If the Token unicast session (See Section 4.3.1). If the Token is invalid or
is invalid or missing, the server sends a new RTCP message, missing, the server sends a Token Verification Failure message
called Token Verification Failure, to the client. (Section 4.4) to the client.
Note that the unicast session is only established after the Note that the unicast session is only established after the
server has received a feedback message (along with a valid Token) server has received a feedback message (along with a valid Token)
from the client for which it needs to react by sending unicast from the client for which it needs to react by sending unicast
data. Until a unicast session is established, neither the server data. Until a unicast session is established, neither the server
nor the client needs to send RTCP reports for the unicast nor the client needs to send RTCP reports for the unicast
session. session.
5. Normal flows ensue as shown in Figure 2. 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
during the lifetime of the unicast session if the unicast during the lifetime of the unicast session if the time between
session's lifetime is likely to exceed the NAT's timeout value. unicast feedback messages (from c1 to P3) is likely to exceed the
NAT's timeout value (For the NAT timeout value requirements, see
[RFC4787]).
A unicast session on a particular receive port c1 can last as long as
the associated multicast session lasts. However, a client cannot
keep using the same receive port c1 for different subsequent unicast
sessions since there could be packet leakage when switching from one
unicast session to another unless each received unicast stream has
its own distinct Synchronization Source (SSRC) identifier to allow
the client to filter out the undesired packets. Unless this is
guaranteed (which is not often easy), a client SHOULD use separate
receive ports for subsequent unicast sessions. After a sufficient
time, a previously used receive port could be used again.
4. Message Formats 4. Message Formats
This section defines the formats of the RTCP messages that are This section defines the formats of the RTCP messages that are
exchanged between a server and a client for the purpose of port exchanged between a server and a client for the purpose of port
mapping. A new RTCP control packet type is introduced and four port mapping. A new RTCP control packet type is introduced and four port
mapping messages using this control packet are defined: mapping messages using this control packet are defined:
1. Port Mapping Request 1. Port Mapping Request
2. Port Mapping Response 2. Port Mapping Response
3. Token Verification Request 3. Token Verification Request
4. Token Verification Failure 4. Token Verification Failure
Each message has a fixed-length field for version (V), padding (P), Each message has a fixed-length field for version (V), padding (P),
sub-message type (SMT), packet type (PT), length and SSRC of packet sub-message type (SMT), packet type (PT), length and SSRC of packet
sender. Messages have other fields as defined below. In all sender. Messages have other fields as defined below. In all
messages defined in this section, the PT field is set to TOKEN (210). messages defined in this section, the PT field is set to TOKEN.
Individual messages are identified by the SMT field. The length Individual messages are identified by the SMT field. The length
field indicates the message size in 32-bit words minus one, including field indicates the message size in 32-bit words minus one, including
the header and any padding. This definition is in line with the the header and any padding. This definition is in line with the
definition of the length field used in RTCP sender and receiver definition of the length field used in RTCP sender and receiver
reports. In all messages, any Reserved field SHALL be set to zero reports. In all messages, any Reserved field SHALL be set to zero
and ignored. and ignored.
Following the rules specified in [RFC3550], all integer fields in the Following the rules specified in [RFC3550], all integer fields in the
messages defined below are carried in network-byte order, that is, messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian. most significant byte (octet) first, also known as big-endian.
skipping to change at page 13, line 4 skipping to change at page 13, line 4
resend its request by following the timer rules defined for RTCP resend its request by following the timer rules defined for RTCP
feedback messages in Section 3.5 of [RFC4585] as a good practice. feedback messages in Section 3.5 of [RFC4585] as a good practice.
When sending an RTCP (feedback) message bundled with a Token When sending an RTCP (feedback) message bundled with a Token
Verification Request message, the timer rules of [RFC4585] apply as Verification Request message, the timer rules of [RFC4585] apply as
usual. usual.
4.1. Port Mapping Request 4.1. Port Mapping Request
The Port Mapping Request message is identified by SMT=1. This The Port Mapping Request message is identified by SMT=1. This
message is transmitted by the client to a dedicated server port (and message is transmitted by the client to a dedicated server port (and
possibly an address) to request a Token. In the Port Mapping Request possibly a dedicated address) to request a Token. In the Port
message, the packet sender SSRC is set to the client's SSRC. The Mapping Request message, the packet sender SSRC is set to the
packet format has the structure depicted in Figure 3. client's SSRC. Here, the SSRC value is not necessarily linked to the
one used by the client in the multicast session. The packet format
has the structure depicted in Figure 3.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=1 | PT=TOKEN=210 | Length=3 | |V=2|P| SMT=1 | PT=TOKEN | Length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random | | Random |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Packet format for the Port Mapping Request message Figure 3: Packet format for the Port Mapping Request message
o Random Nonce (64 bits): Field that contains a random nonce value o Random Nonce (64 bits): Field that contains a random value
generated by the client following the procedures of [RFC4086]. generated by the client following the procedures of [RFC4086].
This nonce is taken into account by the server when generating a This nonce is taken into account by the server when generating a
Token for the client to enable better security for clients that Token for the client to enable better security for clients that
share the same IP address. If the Port Mapping Request message is share the same IP address (Such clients need to produce a random
transmitted multiple times for redundancy reasons, the random value guaranteed to be temporally and globally unique). If the
nonce value MUST remain the same in these duplicated messages. same Port Mapping Request message is transmitted multiple times
However, the client MUST generate a new random nonce for every new for redundancy reasons, the random nonce value MUST remain the
Port Mapping Request message. same in these duplicated messages. However, the client MUST
generate a new random nonce for every new 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=2 | PT=TOKEN=210 | Length | |V=2|P| SMT=2 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client | | SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | | Associated |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute | | Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time | | Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Packet Types Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Packet format for the Port Mapping Response message Figure 4: Packet format for the Port Mapping Response message
o SSRC of Requesting Client (32 bits): Field that contains the SSRC o SSRC of Requesting Client (32 bits): Field that contains the SSRC
of the client who sent the request. of the client who sent the request.
o Associated Nonce (64 bits): Field that contains the nonce o Associated Nonce (64 bits): Field that contains the nonce
received in the Port Mapping Request message and used in Token received in the Port Mapping Request message and used in Token
construction. construction.
skipping to change at page 15, line 9 skipping to change at page 15, line 11
in seconds since year 1900 [RFC5905]. The client does not need to in seconds since year 1900 [RFC5905]. The client does not need to
use this element directly, thus, does not need to synchronize its use this element directly, thus, does not need to synchronize its
clock with the server. However, the client needs to send this clock with the server. However, the client needs to send this
element back to the server along with the associated nonce in the element back to the server along with the associated nonce in the
Token Verification Request message, thus, needs to keep it Token Verification Request message, thus, needs to keep it
associated with the Token. associated with the Token.
o Relative Expiration Time (32 bits): Field that contains the o Relative Expiration Time (32 bits): Field that contains the
relative expiration time of the Token. The relative expiration relative expiration time of the Token. The relative expiration
time is expressed in seconds from the time the Token was time is expressed in seconds from the time the Token was
generated. A relative expiration time of zero indicates that the generated. Whenever a server decides to not grant a Token to a
accompanying Token is not valid. requesting client, the relative expiration time will be set to
zero (and hence, the accompanying Token will be invalid).
The server conveys the relative expiration time in the clear to The server conveys the relative expiration time in the clear to
the client to allow the client to request a new Token well before the client to allow the client to request a new Token well before
the expiration time. the expiration time.
o Packet Types Element (Variable size): Element that is used to
signal which RTCP packet types require Token-based authentication.
This element is a 32-bit aligned Length-Value element. The Length
field, which is 8 bits, indicates the length (in octets) of the
Value field that follows the Length field. This length does not
include any padding that is required for alignment. The Value
field carries zero or more 8-bit sub-fields each carrying an RTCP
packet type. If the Packet Types element does not fall on a 32-
bit boundary, the last word MUST be padded to the boundary using
further bits set to zero.
A server MAY change its policy on which RTCP packet types would
require Token-based authentication based on observations,
configuration or other policies. However, upon such a change the
server SHALL NOT send a new Port Mapping Response message to the
clients who requested a Token earlier. A client learns about this
change when and if it gets a Token Verification Failure message.
4.3. Token Verification Request 4.3. Token Verification Request
The Token Verification Request message is identified by SMT=3. This The Token Verification Request message is identified by SMT=3. This
message contains the Token and accompanies any RTCP message that message contains the Token and accompanies any RTCP message that
would trigger a new or control an existing unicast session. For a would trigger a new or control an existing unicast session. For a
list of such messages, see Section 4.3.1. list of such messages, see Section 4.3.1.
In the Token Verification Request message, the packet sender SSRC is In the Token Verification Request message, the packet sender 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | | Associated |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute | | Associated Absolute |
| Expiration Time | | Expiration Time |
skipping to change at page 16, line 11 skipping to change at page 16, line 35
o Token Element (Variable size): Token element that was previously o Token Element (Variable size): Token element that was previously
received in the Port Mapping Response message. received in the Port Mapping Response message.
o Associated Absolute Expiration Time (64 bits): Field that o Associated Absolute Expiration Time (64 bits): Field that
contains the absolute expiration time associated with the Token contains the absolute expiration time associated with the Token
above. above.
4.3.1. Where to Include Token 4.3.1. Where to Include Token
The following RTCP messages are REQUIRED to be accompanied by a Token This section provides guidelines about which RTCP packet types would
Verification Request message when the Token capability is declared in need to be accompanied by a Token Verification Request message.
the session description: However, since a server might determine in real time that other RTCP
messages also need to be authenticated by a Token, a client MUST act
o Messages that trigger a new unicast session: according to the up-to-date list provided to the client in the Port
Mapping Response message (in the Packet Types element). Clients need
to support using Token-based authentication with any necessary RTCP
message (See Section 3.2).
* NACK messages [RFC4585] As a general rule, when the Token capability is declared in the
session description, the RTCP messages that trigger transmission of
RTP packets in a port-mapped unicast session are REQUIRED to be
authenticated by using a Token. Such messages include but are not
limited to:
* RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp] o NACK messages [RFC4585]
o RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
o Messages that control an existing unicast session associated with Additionally, some RTCP messages might directly or indirectly control
a multicast session: an existing unicast session associated with a multicast session.
Unless another authentication method as described in their respective
specifications is used, such RTCP messages might also need to be
authenticated by using a Token. Examples are:
* BYE messages [RFC3550] o BYE messages [RFC3550]
* RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp] o RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
* CCM messages [RFC5104] o CCM messages [RFC5104]
A server might determine that other RTCP messages also need to be Note that even if a packet type is listed to require Token-based
authenticated using the mechanism described in this document. Thus, authentication, it does not need to be authenticated when it does not
clients need to support including a Token with any necessary RTCP control the unicast session. For example, if BYE (203) is listed in
message (See Section 3.2). the Port Mapping Response message as one of the packet types that
requires authentication, the client does not need to bundle the RTCP
BYE message with a Token when it is sending it for the multicast
session.
The Token Verification Request message might also be bundled with The Token Verification Request message might also be bundled with
packets carrying RTCP receiver or extended reports. While such packets carrying RTCP receiver and/or extended reports. While such
packets do not have a strong security impact, a specific application packets do not have a strong security impact, a specific application
might desire to have a more controlled reporting scheme from the might desire to have a more controlled reporting scheme from the
clients. clients. In this case, the server lists the packet types for the
receiver (201) and/or extended reports (207) in the Port Mapping
Response message.
4.4. Token Verification Failure 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=5 | |V=2|P| SMT=4 | PT=TOKEN | Length=5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client | | SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT of Request | Req. FMT| Reserved | | PT of Request | Req. FMT| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | | Associated |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 23 skipping to change at page 19, line 23
o The nonce generated and inserted in the Port Mapping Request o The nonce generated and inserted in the Port Mapping Request
message by the client (64 bits) message by the client (64 bits)
o The absolute expiration time chosen by the server indicated as an o The absolute expiration time chosen by the server indicated as an
NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits, NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits,
to protect against replay attacks) to protect against replay attacks)
An example way for constructing Tokens is to perform HMAC-SHA1 An example way for constructing Tokens is to perform HMAC-SHA1
[RFC2104] on the concatenated values of the information listed above. [RFC2104] on the concatenated values of the information listed above.
The HMAC key should be at least 160 bits long, and generated using a The HMAC key needs to be at least 160 bits long, and generated using
cryptographically secure random source [RFC4086]. However, a cryptographically secure random source [RFC4086]. While HMAC-SHA1
implementations MAY adopt different approaches and are encouraged to is the RECOMMENDED procedure, implementations might adopt different
encode whatever additional information is deemed necessary or useful. approaches.
For example, key rollover is simplified by encoding a key-id into the
Token. As another example, a cluster of anycast servers could find In addition to the information listed above, implementations are
advantage by encoding a server identifier into the Token. As another encouraged to encode whatever additional information is deemed
example, if HMAC-SHA1 has been compromised, a replacement HMAC necessary or useful. For example, key rollover is simplified by
algorithm could be used instead (e.g., HMAC-SHA256). 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, while HMAC-SHA1 provides a level
of security that is widely regarded as being more than sufficient for
providing message authentication and it is secure against all known
cryptanalytic attacks that use computational resources that are
currently economically feasible, if HMAC-SHA1 has been compromised, a
replacement HMAC algorithm could be used instead (e.g., HMAC-SHA256).
To protect from offline attacks, the server SHOULD occasionally To protect from offline attacks, the server SHOULD occasionally
choose a new HMAC key. To ease implementation, a key-id can be choose a new HMAC key. To ease implementation, a key-id can be
assigned to each HMAC key. This can be encoded as simply as one bit assigned to each HMAC key. This can be encoded as simply as one bit
(where the new key is X (e.g., 1) and the old key is the inverted (where the new key is X (e.g., 1) and the old key is the inverted
value of X (e.g., 0)), or if several keys are supported at once could value of X (e.g., 0)), or if several keys are supported at once could
be encoded into several bits. As the encoding of the Token is be encoded into several bits. As the encoding of the Token is
entirely private to the server and opaque to the clients, any entirely private to the server and opaque to the clients, any
encoding can be used. By encoding the key-id into the Token element, 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 the server can reject an old key without bothering to do HMAC
skipping to change at page 21, line 7 skipping to change at page 22, line 7
RECOMMENDED that applications define an application-specific error RECOMMENDED that applications define an application-specific error
response to be sent by the server when the server detects that the response to be sent by the server when the server detects that the
Token is invalid. For applications using Token is invalid. For applications using
[I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new [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 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 and portmapping-req Attributes
This new SDP attribute is used declaratively to indicate the port and
optionally the address for obtaining a Token. Its presence indicates
that (i) a Token MUST be included in certain feedback messages sent
to the server triggering or controlling a unicast session (The list
of those feedback messages is in Section 4.3.1), and (ii) the client
MUST receive the unicast session's RTP and RTCP packets from the
server on the port from which it sent the RTCP message triggering or
controlling the unicast session.
The formal description of the 'portmapping-req' attribute is defined The 'portmapping' attribute is used declaratively without any
by the following ABNF [RFC5234] syntax: parameters in a multicast block in an SDP description. It provides a
hint information to the SDP recipient that one or more unicast
sessions associated with this multicast session require the use of
Tokens for certain RTCP messages. The 'portmapping-req' attribute is
also used declaratively but in a unicast block. It indicates the
port and optionally the address for obtaining a Token.
portmapping-req-attr = "a=portmapping-req" [":" port [SP nettype SP In an SDP description, there could be one or more multicast sessions
addrtype SP connection-address]] CRLF described, each associated with zero or more unicast sessions. The
recipient of the SDP description infers the association(s) between
the multicast and unicast sessions through the "a=group" line(s).
Here, 'port', 'nettype', 'addrtype' and 'connection-address' are The presence of the 'portmapping' and 'portmapping-req' attribute
defined as specified in Section 9 of [RFC4566]. The 'portmapping- pair indicates that (i) a Token MUST be included in certain feedback
req' attribute SHALL be used as a media-level attribute. messages sent to the server triggering or controlling a unicast
session (See Section 4.3.1), and (ii) the client MUST receive the
unicast session's RTP and RTCP packets from the server on the port
from which it sent the RTCP message triggering or controlling the
unicast session.
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.1). message (See Section 4.3.1).
7.1.1. ABNF Definition of portmapping
The formal description of the 'portmapping' attribute is defined by
the following ABNF [RFC5234] syntax:
portmapping-attr = "a=portmapping"
This attribute SHALL be used as a media-level attribute in a
multicast block in SDP descriptions.
7.1.2. ABNF Definition of portmapping-req
The formal description of the 'portmapping-req' attribute is defined
by the following ABNF [RFC5234] syntax:
portmapping-req-attr = "a=portmapping-req" [":" port [SP nettype SP
addrtype SP connection-address]] CRLF
Here, 'port', 'nettype', 'addrtype' and 'connection-address' are
defined as specified in Section 9 of [RFC4566].
The 'portmapping-req' attribute SHALL be used as a media-level
attribute in a unicast block in SDP descriptions.
In the optional address value, only unicast addresses SHOULD be used In the optional address value, only unicast addresses SHOULD be used
unless one wants to use a multicast address after evaluating the unless one wants to use a multicast address after evaluating the
additional security risks such as non-legit servers generating fake additional security risks such as non-legit servers generating fake
Tokens. If the address is not specified, the (source) address in the Tokens. If the address is not specified, the (source) address in the
"c" line corresponding to the unicast media stream is implied. "c" line corresponding to the unicast media stream is implied.
When using this attribute in SDP offer/answer exchanges [RFC3264], 7.1.3. Offer/Answer Model Considerations
the following needs to be considered. First of all, this attribute
is used declaratively, and there are no offer/answer exchanges
between the client consuming the SDP description and the actual
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 RTCP messages
sent to the server, i.e., received by the server, the attribute is
included. In case an offerer desires to declare support for using
Tokens as defined in this specification but do not need Tokens to be
included for any RTCP messages to be received by the server, it can
include the 'portmapping-req' attribute without any parameters,
neither port nor address.
An answerer receiving an SDP offer with the "a=portmapping-req" line When using the attributes defined above in SDP offer/answer exchanges
with a port number SHALL use that port number and the address, either [RFC3264], the following considerations apply. When an offerer sends
explicitly provided in the attribute or implicitly provided by the an answerer an offer of an SDP description making use of the Token
"c" line, for any needed Token request. If the "a=portmapping-req" approach described in this specification, the 'portmapping' and
line attribute does not contain a port, the answer SHALL take note of 'portmapping-req' attributes are included declaratively. There will
the capability. not be offer/answer exchanges between the answerer and the actual
server providing the unicast service(s).
When sending an answer, if the 'portmapping-req' attribute has been When the answerer supports the Token approach, it MUST echo in its
present in the offer including a port number and the answerer answer back to the offerer the 'portmapping' and 'portmapping-req'
supports this specification, then the answerer MUST include the attributes from the offer including the same port number and address
attribute in its answer. The answer may or may not include a port (if any) for the 'portmapping-req' attribute. If the answerer does
and address. This depends on the application and the desire of the not implement this specification, it follows normal SDP parsing of
answerer. The answerer includes a port and possibly an address when unknown attributes (they are ignored and are not sent in the answer).
it requires to receive Tokens in RTCP messages. If it only supports This means that the answerer can still join the multicast session,
this specification but does not need Tokens to be included, the but will not be able to use the unicast service(s) that require the
attribute is included without any port or address. use of Tokens.
7.2. Requirements 7.2. Requirements
The use of SDP for the port mapping solution normatively requires the The use of SDP for the port mapping solution normatively requires 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]
skipping to change at page 23, line 19 skipping to change at page 24, line 24
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/90000 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=portmapping ; Note 3
a=mid:1 a=mid:1
m=video 42000 RTP/AVPF 99 ; Note 3 m=video 42000 RTP/AVPF 99 ; Note 4
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 5
a=rtcp:42500 ; Note 5 a=rtcp:42500 ; Note 6
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=portmapping-req:30000 ; Note 6 a=portmapping-req:30000 ; Note 7
a=mid:2 a=mid:2
Figure 7: SDP describing an SSM distribution with support for Figure 7: SDP describing an SSM distribution with support for
retransmissions from a local server retransmissions from a local server
In this description, we highlight the following notes: In this description, we highlight the following notes:
Note 1: The source stream is multicast from a distribution source Note 1: The source stream is multicast from a distribution source
with a source IP address of 198.51.100.1 to the multicast destination with a source IP address of 198.51.100.1 to the multicast destination
address of 233.252.0.2 and port 41000 (P1). The associated RTCP address of 233.252.0.2 and port 41000 (P1). The associated RTCP
packets are multicast in the same group to port 41500 (P2). packets are multicast in the same group to port 41500 (P2).
Note 2: A retransmission server including feedback target Note 2: A retransmission server including feedback target
functionality with an IP address of 192.0.2.1 and port of 42000 (P3) functionality with an IP address of 192.0.2.1 and port of 42000 (P3)
is specified with the 'rtcp' attribute. The feedback functionality is specified with the 'rtcp' attribute. The feedback functionality
is enabled for the RTP stream with payload type 98 through the is enabled for the RTP stream with payload type 98 through the
'rtcp-fb' attribute [RFC4585]. 'rtcp-fb' attribute [RFC4585].
Note 3: The port specified in the second "m" line (for the unicast Note 3: The "a=portmapping" line together with the "a=group" line
hints that a Token needs to be retrieved first before the unicast
session can be established.
Note 4: The port specified in the second "m" line (for the unicast
stream) does not mean anything in this scenario as the client does stream) does not mean anything in this scenario as the client does
not send any RTP traffic back to the server. not send any RTP traffic back to the server.
Note 4: The server multiplexes RTP and RTCP packets on the same port Note 5: 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 6: The server uses port 42500 (P4) for the unicast session.
Note 6: The "a=portmapping-req" line indicates that a Token needs to Note 7: The "a=portmapping-req" line indicates that the Port Mapping
be retrieved first before a unicast session associated to the
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 indicated in this line, the client needs to send the Token no address indicated in this line, the client needs to send the Token
request to 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
skipping to change at page 26, line 22 skipping to change at page 27, line 22
cause one or more RTP packets to be sent to a victim client who has a cause one or more RTP packets to be sent to a victim client who has a
different IP address. However, if the attacker acquires a valid different IP address. However, if the attacker acquires a valid
Token for a victim and can spoof the victim's source address, this Token for a victim and can spoof the victim's source address, this
approach becomes vulnerable to replay attacks. This is especially approach becomes vulnerable to replay attacks. This is especially
easy if the attacker and victim are behind a large-scale NAT and easy if the attacker and victim are behind a large-scale NAT and
share the same IP address. share the same IP address.
Multicast is deployed on managed networks - not the Internet. These Multicast is deployed on managed networks - not the Internet. These
managed networks will choose to enable network ingress filtering managed networks will choose 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 cannot spoof a victim's IP address to use a Token to
to initiate an attack against a victim. However, if ingress initiate an attack against a victim. However, if ingress filtering
filtering is not enabled on a network, an attacker could obtain a is not enabled on a network, an attacker could obtain a Token and
Token and spoof the victim's address, causing traffic to flood the spoof the victim's address, causing traffic to flood the victim. On
victim. On such a network, the server can reduce the time period for such a network, the server can reduce the time period for such an
such an attack by expiring a Token in a short period of time. In the attack by expiring a Token in a short period of time. In the extreme
extreme case, the server can expire the Token in such a short period case, the server can expire the Token in such a short period of time,
of time, such that the client will have to acquire a new Token such that the client will have to acquire a new Token immediately
immediately before using it in a Token Verification Request message. before using it in a Token Verification Request message. One should,
however, note that such a behavior might have an adverse effect on
the delay in establishing or controlling a unicast session.
HMAC-SHA1 provides a level of security that is widely regarded as RTCP messages could be subject to on-path or man-in-the-middle
being more than sufficient for providing message authentication. It attacks. For example, an attacker can modify a value in one or more
is believed that the economic cost of breaking that algorithm is fields in the Port Mapping Response or the Token Verification Request
significantly higher than the cost of more direct approaches to message that are used in Token construction. This will result in
violating system security, e.g., theft, bribery, wiretapping, and Token validation failure. Consequently, the client ends up asking
other forms of malfeasance. HMAC-SHA1 is secure against all known the server to generate a new Token. The resulting delay and extra
cryptanalytic attacks that use computational resources that are processing on the server are undesirable.
currently economically feasible.
9.2. The portmapping-req Attribute Alternatively, the attacker can modify a value in a field that is not
used in Token construction. For example, the attacker can reduce the
value in the Relative Expiration Time field in the Port Mapping
Response message from two hours to two minutes. While the Token will
still validate, this attack will result in more frequent requests to
the server for a new Token. Oppositely, the attacker can increase
the value in the Relative Expiration Time field, and make the client
think the Token will be valid for a longer time. This attack can be
only detected by monitoring the activity on the server. Note that
using the relative expiration time in Token construction does not
necessarily make this attack to be detected more easily since the
attacker might revert the modified value back to its original value
in the Token Verification Request message. This allows the Token to
still validate on the server. In this case, the attack is still only
detectable by monitoring the server activity.
If there is a risk or concern for on-path or man-in-the-middle
attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP)
[RFC3711].
9.2. The portmapping and portmapping-req Attributes
The 'portmapping' attribute does not introduce a significant security
risk. It is used for informative purposes as a hint in a multicast
block in SDP descriptions and without the use of the 'portmapping-
req' attribute in an associated unicast block, its existence does not
mean anything and SHALL be ignored. However, if the 'portmapping-
req' attribute exists in the unicast block but the 'portmapping'
attribute is missing in the associated multicast block (which is
inferred through the "a=group" line), the clients MUST still behave
as if the 'portmapping' attribute existed in the multicast block.
The 'portmapping-req' attribute is not believed to introduce any The 'portmapping-req' attribute is not believed to introduce any
significant security risk to multimedia applications. A malevolent significant security risk to multimedia applications. A malevolent
third party could use this attribute to redirect the Port Mapping third party could use this attribute to redirect the Port Mapping
Request messages by altering the port number or cause the unicast Request messages by altering the port number or cause the unicast
session establishment to fail by removing it from the SDP session establishment to fail by removing it from the SDP
description. But, this requires intercepting and rewriting the description. But, this requires intercepting and rewriting the
packets carrying the SDP description; and if an interceptor can do packets carrying the SDP description; and if an interceptor can do
that, many more attacks are possible, including a wholesale change of that, many more attacks are possible, including a wholesale change of
the addresses and port numbers at which the media will be sent. the addresses and port numbers at which the media will be sent.
skipping to change at page 28, line 18 skipping to change at page 29, line 18
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.
10.1. Registration of SDP Attributes 10.1. Registration of SDP Attributes
This document registers a new attribute name in SDP. This document registers two new attribute names in SDP.
SDP Attribute ("att-field"):
Attribute name: portmapping
Long form: Hint for the use of port mapping
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: [RFCXXXX]
Values: See this document
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 and address for requesting Token
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: See this document
Reference: [RFCXXXX] Reference: [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] TBD TOKEN Port Mapping [RFCXXXX]
Note to the IANA: Please assign the next available value, which is
currently 210.
10.3. SMT Values for TOKEN Packet Type Registry 10.3. SMT Values for TOKEN Packet Type Registry
This document creates a new sub-registry for the sub-message type This document creates a new sub-registry for the sub-message type
(SMT) values to be used with the TOKEN packet type. The registry is (SMT) values to be used with the TOKEN packet type. The registry is
called the SMT Values for TOKEN Packet Type Registry. This registry called the SMT Values for TOKEN Packet Type Registry. This registry
is to be managed by the IANA according to the IETF Review policy of is to be managed by the IANA according to the IETF Review policy of
[RFC5226]. [RFC5226].
The length of the SMT field is five bits, allowing 32 values. The The length of the SMT field is five bits, allowing 32 values. The
skipping to change at page 31, line 48 skipping to change at page 32, line 48
[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.
[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.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
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,
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.
 End of changes. 63 change blocks. 
192 lines changed or deleted 320 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/