draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01.txt   draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.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: September 14, 2011 T. VanCaenegem Expires: October 17, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
March 13, 2011 April 15, 2011
Port Mapping Between Unicast and Multicast RTP Sessions Port Mapping Between Unicast and Multicast RTP Sessions
draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02
Abstract Abstract
This document presents a port mapping solution that allows RTP This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services. The in RTP applications using both unicast and multicast services. The
solution provides protection against denial-of-service or packet solution provides protection against denial-of-service or packet
amplification attacks that could be used to cause one or more RTP amplification attacks that could be used to cause one or more RTP
packets to be sent to a victim client. packets to be sent to a victim client.
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 September 14, 2011. This Internet-Draft will expire on October 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . 13 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 14 4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 14
4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 14 4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 14
4.3. Token Verification Request . . . . . . . . . . . . . . . . 17 4.3. Token Verification Request . . . . . . . . . . . . . . . . 17
4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 17 4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 18
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 18 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 19
5. Procedures for Token Construction . . . . . . . . . . . . . . 20 5. Procedures for Token Construction . . . . . . . . . . . . . . 21
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 22 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 23
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 23 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 23 7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 24
7.1.1. ABNF Definition of portmapping-req . . . . . . . . . . 23 7.1.1. ABNF Definition of portmapping-req . . . . . . . . . . 24
7.1.2. Offer/Answer Model Considerations . . . . . . . . . . 23 7.1.2. Offer/Answer Model Considerations . . . . . . . . . . 24
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 24 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 25
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 27 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. The portmapping and portmapping-req Attributes . . . . . . 29 9.2. The portmapping and portmapping-req Attributes . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 30 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 31
10.2. Registration of RTCP Control Packet Types . . . . . . . . 30 10.2. Registration of RTCP Control Packet Types . . . . . . . . 31
10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 30 10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 31
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 31 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
In (any-source or source-specific) multicast RTP applications, In (any-source or source-specific) multicast RTP applications,
destination ports, i.e., the ports on which the multicast receivers destination ports, i.e., the ports on which the multicast receivers
receive the RTP and RTCP packets, are defined declaratively. In receive the RTP and 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 3, line 36 skipping to change at page 3, line 36
sessions with other endpoints. sessions with other endpoints.
In this specification, we consider an RTP application that uses one In this specification, we consider an RTP application that uses one
or more unicast and multicast RTP sessions together. While the or more unicast and multicast RTP sessions together. While the
declaration and selection of the ports are well defined and work well declaration and selection of the ports are well defined and work well
for multicast and unicast RTP applications, respectively, the usage for multicast and unicast RTP applications, respectively, the usage
of the ports introduces complications when a receiving end mixes of the ports introduces complications when a receiving end mixes
unicast and multicast RTP sessions within the same RTP application. unicast and multicast RTP sessions within the same RTP application.
An example scenario is where the RTP packets are distributed through An example scenario is where the RTP packets are distributed through
source-specific multicast (SSM) and a receiver sends unicast RTCP source-specific multicast (SSM) [RFC4607] and a receiver sends
NACK feedback to a local repair server (also functioning as a unicast unicast RTCP NACK feedback to a local repair server (also functioning
RTCP feedback target) [RFC5760] asking for a retransmission of the as a unicast RTCP feedback target) [RFC5760] asking for a
packets it is missing, and the local repair server sends the retransmission of the packets it is missing, and the local repair
retransmission packets over a unicast RTP session [RFC4588]. server sends the retransmission packets over a unicast RTP session
[RFC4588].
Another scenario is where a receiver wants to rapidly acquire a new Another scenario is where a receiver wants to rapidly acquire a new
primary multicast RTP session and receives one or more RTP burst primary multicast RTP session and receives one or more RTP burst
packets over a unicast session before joining the SSM session packets over a unicast session before joining the SSM session
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Similar scenarios exist in
applications where some part of the content is distributed through applications where some part of the content is distributed through
multicast while the receivers get additional and/or auxiliary content multicast while the receivers get additional and/or auxiliary content
through one or more unicast connections, as sketched in Figure 1. through one or more unicast connections, as sketched in Figure 1.
In this document, we discuss this problem and introduce a solution In this document, we discuss this problem and introduce a solution
skipping to change at page 6, line 7 skipping to change at page 6, line 7
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Token-Based Port Mapping 3. Token-Based Port Mapping
Token-based Port Mapping consists of the server providing the client
a Token that can be used to establish a unicast session, without the
possibility of an attacker redirecting traffic to an unsuspecting
third party to create a DoS attack. The Token is essentially an
opaque encapsulation that is based on client's IP address (as seen by
the server), a time-to-live value and a random nonce provided by the
client.
Token-based Port Mapping consists of two steps: (i) Token request Token-based Port Mapping consists of two steps: (i) Token request
and retrieval, and (ii) unicast session establishment. and retrieval, and (ii) unicast session establishment.
When a Token request is received, the server creates a Token for this
particular client, and sends it back to the client.
Once a Token is retrieved from a particular server, it can be used Once a Token is retrieved from a particular server, it can be used
for all the unicast sessions the client will be running with this for all the unicast sessions the client will be running with this
particular server till the Token expires. By default, Tokens are particular server till the Token expires. By default, Tokens are
server specific. However, the client can use the same Token to server specific. However, the client can use the same Token to
communicate with different servers if these servers are provided with communicate with different servers if these servers are provided with
the same secret key and algorithm used to generate the Token and are the same secret key and algorithm used to generate the Token and are
at least loosely clock-synchronized. at least loosely clock-synchronized.
The Token is essentially an opaque encapsulation that is based on The Token becomes invalid if client's IP address (as seen by the
client's IP address (as seen by the server). When a Token request is server) changes (note that the client cannot necessarily detect this
received, the server creates a Token for this particular client, and in a timely manner) or when the server expires the Token. In these
sends it back to the client. The Token becomes invalid if client's cases, the client has to request a new Token.
IP address (as seen by the server) changes (note that the client
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
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.
skipping to change at page 7, line 16 skipping to change at page 7, line 24
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, we assume there sketched in Figure 2. Between the client and server, we assume there
exists at least one NAT device [RFC4787] (If there is no NAT devices exists at least one NAT device [RFC4787] (If there are no NAT devices
between the server and client, the method still works the same between the server and client, the method still works the same
fashion). The multicast and unicast sessions are clearly identified fashion). The multicast and unicast sessions are clearly identified
with their individual RTP and RTCP flows and port numbers. with their individual RTP and RTCP flows and port numbers.
-------------- --- ---------- -------------- --- ----------
| |-------------------------------| |-->|P1 | | |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 | | |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | | | | | | | |
| Distribution | ---------------- | | | | | Distribution | ---------------- | | | |
| Source | | | | | | | | Source | | | | | | |
skipping to change at page 11, line 25 skipping to change at page 11, line 25
5. Normal flows ensue as shown in Figure 2. It is strongly 5. Normal flows ensue as shown in Figure 2. It is strongly
RECOMMENDED that the client uses the same port for both c0 and RECOMMENDED that the client uses the same port for both c0 and
c1, as this causes the periodic RTCP reports to keep the NAT c1, as this causes the periodic RTCP reports to keep the NAT
mapping alive. However, if the client uses different ports for mapping alive. However, if the client uses different ports for
c0 and c1, the client MUST keep its own NAT mapping alive for the c0 and c1, the client MUST keep its own NAT mapping alive for the
P3->c1 session (See [I-D.ietf-avt-app-rtp-keepalive] for P3->c1 session (See [I-D.ietf-avt-app-rtp-keepalive] for
additional information). additional information).
In the unicast session, traffic from the server to the client In the unicast session, traffic from the server to the client
(i.e., both the RTP and RTCP packets sent from port P3 towards (i.e., both the RTP and RTCP packets sent from port P3 towards
port c1) MUST be multiplexed on the (same) port c1. port c1) MUST be multiplexed on the (same) port c1 [RFC5761].
The client sends the RTCP receiver and extended reports in the The client sends the RTCP receiver and extended reports in the
unicast session from port c2 towards port P4. The server unicast session from port c2 towards port P4. The server
correlates these reports with the reports received in the correlates these reports with the reports received in the
multicast session based on the client's RTCP Canonical Name multicast session based on the client's RTCP Canonical Name
(CNAME). Thus, the client MUST use the same RTCP CNAME in both (CNAME). Thus, the client MUST use the same RTCP CNAME in both
sessions and its RTCP CNAME MUST be unique sessions and its RTCP CNAME MUST be unique [RFC6222].
[I-D.ietf-avt-rtp-cnames].
A unicast session on a particular receive port c1 can last as long as A unicast session on a particular receive port c1 can last as long as
the associated multicast session lasts. However, a client cannot the associated multicast session lasts. However, a client cannot
keep using the same receive port c1 for different subsequent unicast keep using the same receive port c1 for different subsequent unicast
sessions since there could be packet leakage when switching from one sessions since there could be packet leakage when switching from one
unicast session to another unless each received unicast stream has unicast session to another unless each received unicast stream has
its own distinct Synchronization Source (SSRC) identifier to allow its own distinct Synchronization Source (SSRC) identifier to allow
the client to filter out the undesired packets. Unless this is the client to filter out the undesired packets. Unless this is
guaranteed (which is not often easy), a client SHOULD use separate guaranteed (which is not often easy), a client SHOULD use separate
receive ports for subsequent unicast sessions. After a sufficient receive ports for subsequent unicast sessions. After a sufficient
skipping to change at page 15, line 38 skipping to change at page 15, line 38
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.
o Token Element (Variable size): Element that is used to carry the o Token Element (Variable size): Element that is used to carry the
Token generated by the server. This element is a 32-bit aligned Token generated by the server. This element is a 32-bit aligned
Length-Value element. The Length field, which is 8 bits, Length-Value element. The Length field, which is 16 bits,
indicates the length (in octets) of the Value field that follows indicates the length (in octets) of the Value field that follows
the Length field. This length does not include any padding that the Length field. While a 16-bit length allows for Tokens with a
is required for alignment. The Value field carries the Token (or size of up to 65535 bytes, using Tokens of sizes that make the
more accurately, the output of the encoding process on the RTCP compound packet larger than the MTU might have a negative
server). If the Token element does not fall on a 32-bit boundary, impact on functionality because of IP fragmentation. Some NATs or
the last word MUST be padded to the boundary using further bits other middleboxes do not pass IP fragments, thus a large Token can
set to zero. cause the whole mechanism to fail. In addition, fragmentation
increases the risk for packet loss.
The length does not include any padding that 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): Field that contains the o Absolute Expiration Time (64 bits): Field that contains the
absolute expiration time of the Token. The absolute expiration absolute expiration time of the Token. The absolute expiration
time is expressed as a Network Time Protocol (NTP) timestamp value time is expressed as a Network Time Protocol (NTP) timestamp value
in seconds since year 1900 [RFC5905]. The client does not need to in seconds since 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.
skipping to change at page 20, line 21 skipping to change at page 21, line 21
o Client's IP address as seen by the server (32/128 bits for IPv4/ o Client's IP address as seen by the server (32/128 bits for IPv4/
IPv6 addresses) IPv6 addresses)
o The nonce generated and inserted in the Port Mapping Request o The nonce generated and inserted in the Port Mapping Request
message by the client (64 bits) message by the client (64 bits)
o The absolute expiration time chosen by the server indicated as an o The absolute expiration time chosen by the server indicated as an
NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits, NTP timestamp value in seconds since 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 The RECOMMENDED way for constructing Tokens is to perform HMAC-SHA1
[RFC2104] on the concatenated values of the information listed above. [RFC2104] on the concatenated values of the information listed above
The HMAC key needs to be at least 160 bits long, and generated using (Implementations might adopt different approaches). If HMAC-SHA1 is
a cryptographically secure random source [RFC4086]. While HMAC-SHA1 used, the HMAC key MUST be at least 160 bits long, and generated
is the RECOMMENDED procedure, implementations might adopt different using a cryptographically secure random source [RFC4086].
approaches.
In addition to the information listed above, implementations are In addition to the information listed above, implementations are
encouraged to encode whatever additional information is deemed encouraged to encode whatever additional information is deemed
necessary or useful. For example, key rollover is simplified by necessary or useful. For example, key rollover is simplified by
encoding a key-id into the Token. As another example, a cluster of encoding a key-id into the Token. As another example, a cluster of
anycast servers could find advantage by encoding a server identifier anycast servers could find advantage by encoding a server identifier
into the Token. As another example, while HMAC-SHA1 provides a level into the Token. As another example, while HMAC-SHA1 provides a level
of security that is widely regarded as being more than sufficient for of security that is widely regarded as being more than sufficient for
providing message authentication and it is secure against all known providing message authentication and it is secure against all known
cryptanalytic attacks that use computational resources that are cryptanalytic attacks that use computational resources that are
skipping to change at page 21, line 7 skipping to change at page 22, line 7
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
validation (saving CPU cycles). The key-id can be encoded into the validation (saving CPU cycles). The key-id can be encoded into the
Value field of the Token element by simply concatenating the Value field of the Token element by simply concatenating the
(plaintext) key-id with the hashed information (i.e., the Token (plaintext) key-id with the hashed information (i.e., the Token
itself). itself).
For example, the Value field in the Token element can be computed as: For example, the Value field in the Token element can be computed as:
key-id || hash-alg (client-ip | nonce | abs-expiration) key-id || mac-alg (client-ip | nonce | abs-expiration)
During Token construction, the expiration time has to be chosen During Token construction, the expiration time has to be chosen
carefully based on the intended service duration. Tokens that are carefully based on the intended service duration. Tokens that are
valid for an unnecessarily long period of time (e.g., several hours) valid for an unnecessarily long period of time (e.g., several hours)
might impose security risks. Depending on the application and use might impose security risks. Depending on the application and use
cases, a reasonable value needs to be chosen by the server. Note cases, a reasonable value needs to be chosen by the server. Note
that using shorter lifetimes requires the clients to acquire Tokens that using shorter lifetimes requires the clients to acquire Tokens
more frequently. However, since a client can acquire a new Token more frequently. However, since a client can acquire a new Token
well before it will need to use it, the client will not necessarily well before it will need to use it, the client will not necessarily
be penalized for the acquisition delay. be penalized for the acquisition delay.
skipping to change at page 24, line 28 skipping to change at page 25, line 28
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 Multiplexing RTP and RTCP on a single port on both endpoints in o The 'rtcp-mux' attribute (To multiplex RTP and RTCP on a single
the unicast session [RFC5761] port on both endpoints in the unicast session [RFC5761])
7.3. Example and Discussion 7.3. Example and Discussion
The declarative SDP describing the scenario given in Figure 2 is The declarative SDP describing the scenario given in Figure 2 is
written as: written as:
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions s=Local Retransmissions
t=0 0 t=0 0
skipping to change at page 28, line 40 skipping to change at page 29, line 40
before using it in a Token Verification Request message. One should, before using it in a Token Verification Request message. One should,
however, note that such a behavior might have an adverse effect on however, note that such a behavior might have an adverse effect on
the delay in establishing or controlling a unicast session. the delay in establishing or controlling a unicast session.
RTCP messages could be subject to on-path or man-in-the-middle RTCP messages could be subject to on-path or man-in-the-middle
attacks. For example, an attacker can modify a value in one or more attacks. For example, an attacker can modify a value in one or more
fields in the Port Mapping Response or the Token Verification Request fields in the Port Mapping Response or the Token Verification Request
message that are used in Token construction. This will result in message that are used in Token construction. This will result in
Token validation failure. Consequently, the client ends up asking Token validation failure. Consequently, the client ends up asking
the server to generate a new Token. The resulting delay and extra the server to generate a new Token. The resulting delay and extra
processing on the server are undesirable. processing on the server is undesirable.
Alternatively, the attacker can modify a value in a field that is not Alternatively, the attacker can modify a value in a field that is not
used in Token construction. For example, the attacker can reduce the used in Token construction. For example, the attacker can reduce the
value in the Relative Expiration Time field in the Port Mapping value in the Relative Expiration Time field in the Port Mapping
Response message from two hours to two minutes. While the Token will Response message from two hours to two minutes. While the Token will
still validate, this attack will result in more frequent requests to still validate, this attack will result in more frequent requests to
the server for a new Token. Oppositely, the attacker can increase the server for a new Token. Oppositely, the attacker can increase
the value in the Relative Expiration Time field, and make the client the value in the Relative Expiration Time field, and make the client
think the Token will be valid for a longer time. This attack can be think the Token will be valid for a longer time. This attack can be
only detected by monitoring the activity on the server. Note that only detected by monitoring the activity on the server. Note that
skipping to change at page 29, line 13 skipping to change at page 30, line 13
necessarily make this attack easier to detect since the attacker necessarily make this attack easier to detect since the attacker
might revert the modified value back to its original value in the might revert the modified value back to its original value in the
Token Verification Request message. This allows the Token to still Token Verification Request message. This allows the Token to still
validate on the server. In this case, the attack is still only validate on the server. In this case, the attack is still only
detectable by monitoring the server activity. detectable by monitoring the server activity.
If there is a risk or concern for on-path or man-in-the-middle If there is a risk or concern for on-path or man-in-the-middle
attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP) attacks, RTCP messages SHOULD be protected by Secure RTCP (SRTCP)
[RFC3711]. [RFC3711].
A server MUST NOT use the same secret key it used for Token
construction for other purposes to minimize the risk for cross-
protocol attacks.
9.2. The portmapping and portmapping-req Attributes 9.2. The portmapping and portmapping-req Attributes
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
skipping to change at page 33, line 52 skipping to change at page 34, line 52
[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. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[I-D.ietf-avt-rtp-cnames] [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", draft-ietf-avt-rtp-cnames-05 (work in (CNAMEs)", RFC 6222, April 2011.
progress), January 2011.
12.2. Informative References 12.2. Informative References
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[I-D.ietf-avt-rapid-acquisition-for-rtp] [I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
 End of changes. 23 change blocks. 
67 lines changed or deleted 85 lines changed or added

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