draft-ietf-avt-ports-for-ucast-mcast-rtp-10.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-11.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 23, 2011 T. VanCaenegem Expires: July 9, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
December 20, 2010 January 5, 2011
Port Mapping Between Unicast and Multicast RTP Sessions Port Mapping Between Unicast and Multicast RTP Sessions
draft-ietf-avt-ports-for-ucast-mcast-rtp-10 draft-ietf-avt-ports-for-ucast-mcast-rtp-11
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 23, 2011. This Internet-Draft will expire on July 9, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6
3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 7 3.1. Motivating Scenario . . . . . . . . . . . . . . . . . . . 6
3.2. Normative Behavior and Requirements . . . . . . . . . . . 9 3.2. Normative Behavior and Requirements . . . . . . . . . . . 9
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 16
4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16 4.3.1. Where to Include Token . . . . . . . . . . . . . . . . 16
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 17 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 17
5. Procedures for Token Construction . . . . . . . . . . . . . . 19 5. Procedures for Token Construction . . . . . . . . . . . . . . 19
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 21 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 21
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 22 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. The portmapping and portmapping-req Attributes . . . . . . 22 7.1. The portmapping and portmapping-req Attributes . . . . . . 22
7.1.1. ABNF Definition of portmapping . . . . . . . . . . . . 22 7.1.1. ABNF Definition of portmapping . . . . . . . . . . . . 22
7.1.2. ABNF Definition of portmapping-req . . . . . . . . . . 22 7.1.2. ABNF Definition of portmapping-req . . . . . . . . . . 22
7.1.3. Offer/Answer Model Considerations . . . . . . . . . . 23 7.1.3. Offer/Answer Model Considerations . . . . . . . . . . 23
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 6, line 40 skipping to change at page 6, line 40
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 successful 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 the unicast session lifetime, certain actions and terminated. During the lifetime of a unicast session, a client might
messages by the client might need to be authorized by the server by need to send RTCP messages that require authorization. Since such
requiring a valid Token. Therefore, the server will need the client messages require a valid Token for authorization, the client needs to
to also include the Token along with the RTCP messages that are include the Token along with such RTCP messages as explained in
different from the RTCP message that triggerred the unicast session detail in later sections of this document.
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
skipping to change at page 13, line 6 skipping to change at page 13, line 6
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 a dedicated address) to request a Token. In the Port possibly a dedicated address) to request a Token. In the Port
Mapping Request message, the packet sender SSRC is set to the Mapping Request message, the packet sender SSRC is set to the
client's SSRC. Here, the SSRC value is not necessarily linked to the client's SSRC, which is chosen randomly by the client. The packet
one used by the client in the multicast session. The packet format format has the structure depicted in Figure 3.
has the structure depicted in Figure 3.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=1 | PT=TOKEN | Length=3 | |V=2|P| SMT=1 | PT=TOKEN | Length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random | | Random |
| Nonce | | Nonce |
skipping to change at page 15, line 28 skipping to change at page 15, line 28
o Packet Types Element (Variable size): Element that is used to o Packet Types Element (Variable size): Element that is used to
signal which RTCP packet types require Token-based authentication. signal which RTCP packet types require Token-based authentication.
This element is a 32-bit aligned Length-Value element. The Length This element is a 32-bit aligned Length-Value element. The Length
field, which is 8 bits, indicates the length (in octets) of the field, which is 8 bits, indicates the length (in octets) of the
Value field that follows the Length field. This length does not Value field that follows the Length field. This length does not
include any padding that is required for alignment. The Value include any padding that is required for alignment. The Value
field carries zero or more 8-bit sub-fields each carrying an RTCP field carries zero or more 8-bit sub-fields each carrying an RTCP
packet type. If the Packet Types element does not fall on a 32- packet type. If the Packet Types element does not fall on a 32-
bit boundary, the last word MUST be padded to the boundary using bit boundary, the last word MUST be padded to the boundary using
further bits set to zero. further bits set to zero. An example Packet Types element is
shown in Figure 5.
A server MAY change its policy on which RTCP packet types would A server MAY change its policy on which RTCP packet types would
require Token-based authentication based on observations, require Token-based authentication based on observations,
configuration or other policies. However, upon such a change the configuration or other policies. However, upon such a change the
server SHALL NOT send a new Port Mapping Response message to the server SHALL NOT send a new Port Mapping Response message to the
clients who requested a Token earlier. A client learns about this clients who requested a Token earlier. A client learns about this
change when and if it gets a Token Verification Failure message. change when and if it gets a Token Verification Failure message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length=4 | 205 | 206 | 203 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 204 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example Packet Types element
4.3. Token Verification Request 4.3. Token Verification Request
The Token Verification Request message is identified by SMT=3. This The Token Verification Request message is identified by SMT=3. This
message contains the Token and accompanies any RTCP message that message contains the Token and accompanies any RTCP message that
would trigger a new or control an existing unicast session. For a would trigger a new 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 6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=3 | PT=TOKEN | Length | |V=2|P| SMT=3 | PT=TOKEN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | | Associated |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute | | Associated Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Packet format for the Token Verification Request message Figure 6: Packet format for the Token Verification Request message
o Associated Nonce (64 bits): Field that contains the nonce o Associated Nonce (64 bits): Field that contains the nonce
associated with the Token above. associated with the Token above.
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.
skipping to change at page 17, line 42 skipping to change at page 18, line 5
Response message. Response message.
4.4. Token Verification Failure 4.4. Token Verification Failure
The Token Verification Failure message is identified by SMT=4. This The Token Verification Failure message is identified by SMT=4. This
message is sent by the server and notifies the client that the Token message is sent by the server and notifies the client that the Token
was invalid or that the client did not include a Token Verification was invalid or that the client did not include a Token Verification
Request message in the RTCP packet although it was supposed to. 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 7.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SMT=4 | PT=TOKEN | Length=5 | |V=2|P| SMT=4 | PT=TOKEN | Length=5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client | | SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT of Request | Req. FMT| Reserved | | Failed PT | FMT | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated | | Associated |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packet format for the Token Verification Failure message Figure 7: Packet format for the Token Verification Failure 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 verification request. of the client who sent the verification request.
o PT of Request (8 bits): Field that indicates the type of the RTCP o Failed PT (8 bits): Field that indicates the type of the RTCP
packet that caused this failure message. packet that caused this failure message.
o Req. FMT (5 bits): Field that indicates the feedback message type o FMT (5 bits): Field that indicates the feedback message type
(FMT) value of the RTCP packet that caused this failure. Together (FMT) value of the RTCP packet that caused this failure. Together
with the field above, the client can infer which RTCP message it with the field above, the client can infer which RTCP message it
has previously sent caused this failure message to be sent by the has previously sent caused this failure message to be sent by the
server. For example, if the client did not include a valid Token server. For example, if the client did not include a valid Token
with an RTCP NACK message, the PT of Request field will indicate with an RTCP NACK message, the Failed PT field will indicate 205
205 (RTPFB) and the Req. FMT field will indicate 1 (Generic NACK). (RTPFB) and the FMT field will indicate 1 (Generic NACK). If the
If the RTCP message did not have an associated FMT value (such as RTCP message did not have an associated FMT value (such as an RTCP
an RTCP BYE message), the Req. FMT field SHALL be set to zero. BYE message), the FMT field SHALL be set to zero.
o Associated Nonce (64 bits): Field that contains the nonce o Associated Nonce (64 bits): Field that contains the nonce
received in the Token Verification Request message. If there was received in the Token Verification Request message. If there was
no Token Verification Request message included by the client, this no Token Verification Request message included by the client, this
field is set to 0. field is set to 0.
5. Procedures for Token Construction 5. Procedures for Token Construction
The Token encoding is known to the server but opaque to the client. The Token encoding is known to the server but opaque to the client.
Implementations MUST encode the following information into the Token Implementations MUST encode the following information into the Token
skipping to change at page 24, line 37 skipping to change at page 24, line 37
i=Unicast Retransmission Stream i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=sendonly a=sendonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp-mux ; Note 5 a=rtcp-mux ; Note 5
a=rtcp:42500 ; Note 6 a=rtcp:42500 ; Note 6
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=portmapping-req:30000 ; Note 7 a=portmapping-req:30000 ; Note 7
a=mid:2 a=mid:2
Figure 7: SDP describing an SSM distribution with support for Figure 8: SDP describing an SSM distribution with support for
retransmissions from a local server retransmissions from a local server
In this description, we highlight the following notes: In this description, we highlight the following notes:
Note 1: The source stream is multicast from a distribution source Note 1: The source stream is multicast from a distribution source
with a source IP address of 198.51.100.1 to the multicast destination with a source IP address of 198.51.100.1 to the multicast destination
address of 233.252.0.2 and port 41000 (P1). The associated RTCP address of 233.252.0.2 and port 41000 (P1). The associated RTCP
packets are multicast in the same group to port 41500 (P2). packets are multicast in the same group to port 41500 (P2).
Note 2: A retransmission server including feedback target Note 2: A retransmission server including feedback target
skipping to change at page 27, line 52 skipping to change at page 27, line 52
Alternatively, the attacker can modify a value in a field that is not Alternatively, the attacker can modify a value in a field that is not
used in Token construction. For example, the attacker can reduce the used in Token construction. For example, the attacker can reduce the
value in the Relative Expiration Time field in the Port Mapping value in the Relative Expiration Time field in the Port Mapping
Response message from two hours to two minutes. While the Token will Response message from two hours to two minutes. While the Token will
still validate, this attack will result in more frequent requests to still validate, this attack will result in more frequent requests to
the server for a new Token. Oppositely, the attacker can increase the server for a new Token. Oppositely, the attacker can increase
the value in the Relative Expiration Time field, and make the client the value in the Relative Expiration Time field, and make the client
think the Token will be valid for a longer time. This attack can be think the Token will be valid for a longer time. This attack can be
only detected by monitoring the activity on the server. Note that only detected by monitoring the activity on the server. Note that
using the relative expiration time in Token construction does not using the relative expiration time in Token construction does not
necessarily make this attack to be detected more easily since the necessarily make this attack easier to detect since the attacker
attacker might revert the modified value back to its original value might revert the modified value back to its original value in the
in the Token Verification Request message. This allows the Token to Token Verification Request message. This allows the Token to still
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].
9.2. The portmapping and portmapping-req Attributes 9.2. The portmapping and portmapping-req Attributes
The 'portmapping' attribute does not introduce a significant security The 'portmapping' attribute does not introduce a significant security
risk. It is used for informative purposes as a hint in a multicast risk. It is used for informative purposes as a hint in a multicast
 End of changes. 21 change blocks. 
33 lines changed or deleted 42 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/