draft-ietf-avt-ports-for-ucast-mcast-rtp-07.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-08.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 13, 2011 T. VanCaenegem Expires: June 14, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
December 10, 2010 December 11, 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-07 draft-ietf-avt-ports-for-ucast-mcast-rtp-08
Abstract Abstract
This document presents a port mapping solution that allows RTP This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services. The in RTP applications using both unicast and multicast services. The
solution provides protection against denial-of-service attacks that solution provides protection against denial-of-service attacks that
could be used to cause one or more RTP packets to be sent to a victim could be used to cause one or more RTP packets to be sent to a victim
client. 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 13, 2011. This Internet-Draft will expire on June 14, 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 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6
3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 6 3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 6
3.2. Unicast Session Establishment . . . . . . . . . . . . . . 6 3.2. Unicast Session Establishment . . . . . . . . . . . . . . 6
3.2.1. Motivating Scenario . . . . . . . . . . . . . . . . . 6 3.2.1. Motivating Scenario . . . . . . . . . . . . . . . . . 6
3.2.2. Normative Behavior and Requirements . . . . . . . . . 9 3.2.2. Normative Behavior and Requirements . . . . . . . . . 9
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 12 4.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 11
4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 12 4.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 12
4.3. Token Verification Request . . . . . . . . . . . . . . . . 14 4.3. Token Verification Request . . . . . . . . . . . . . . . . 14
4.4. Token Verification Failure . . . . . . . . . . . . . . . . 15 4.4. Token Verification Failure . . . . . . . . . . . . . . . . 15
5. Procedures for Token Construction . . . . . . . . . . . . . . 17 5. Procedures for Token Construction . . . . . . . . . . . . . . 17
6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 19 6. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 19
7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 20 7. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 20 7.1. The portmapping-req Attribute . . . . . . . . . . . . . . 20
7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 21 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 21
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 24 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 25 9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 27 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 27
10.2. Registration of FMT Values . . . . . . . . . . . . . . . . 27 10.2. Registration of RTCP Control Packet Types . . . . . . . . 27
10.3. SFMT Values for Port Mapping Messages Registry . . . . . . 27 10.3. SMT Values for TOKEN Packet Type Registry . . . . . . . . 27
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 28 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
In (any-source or source-specific) multicast RTP applications, In (any-source or source-specific) multicast RTP applications,
skipping to change at page 7, line 42 skipping to change at page 7, line 42
RTP SESSION | | | | | | RTP SESSION | | | | | |
| P3|........| |..>|*c1 | | P3|........| |..>|*c1 |
| P3|=.=.=.=.| |=.>|*c1 | | P3|=.=.=.=.| |=.>|*c1 |
| P4|<.=.=.=.| |=.=|*c2 | | P4|<.=.=.=.| |=.=|*c2 |
| | | | | | | | | | | |
---------------- --- ---------- ---------------- --- ----------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP (Feedback) Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 2: Example scenario showing an SSM distribution with support Figure 2: Example scenario showing an SSM distribution with support
for retransmissions from a server for retransmissions from a server
In Figure 2, we have the following multicast and unicast ports: In Figure 2, we have the following multicast and unicast ports:
o Ports P1 and P2 denote the destination RTP and RTCP ports in the o Ports P1 and P2 denote the destination RTP and RTCP ports in the
multicast session, respectively. The clients listen to these multicast session, respectively. The clients listen to these
ports to receive the multicast RTP and RTCP packets. Ports P1 and ports to receive the multicast RTP and RTCP packets. Ports P1 and
skipping to change at page 11, line 7 skipping to change at page 11, line 7
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 unicast
session's lifetime is likely to exceed the NAT's timeout value. session's lifetime is likely to exceed the NAT's timeout value.
4. Message Formats 4. Message Formats
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP messages that are
messages that are exchanged between a server and a client for the exchanged between a server and a client for the purpose of port
purpose of Token-based port mapping. Four RTCP messages are defined: mapping. A new RTCP control packet type is introduced and four port
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
These are all payload-independent RTCP feedback messages with a Each message has a fixed-length field for version (V), padding (P),
common format defined in Section 6.1 of [RFC4585], also sketched in sub-message type (SMT), packet type (PT), length and SSRC of packet
Figure 3. sender. Messages have other fields as defined below. In all
messages defined in this section, the PT field is set to TOKEN (210).
0 1 2 3 Individual messages are identified by the SMT field. The length
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 field indicates the message size in 32-bit words minus one, including
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the header and any padding. This definition is in line with the
|V=2|P| FMT | PT | length | definition of the length field used in RTCP sender and receiver
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reports. In all messages, any Reserved field SHALL be set to zero
| SSRC of packet sender | and ignored.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 3: The common packet format for the RTCP feedback messages
Each feedback message has a fixed-length field for version, padding,
feedback message type (FMT), packet type (PT), length, SSRC of packet
sender, SSRC of media source as well as a variable-length field for
feedback control information (FCI).
In the new messages defined in this section, the PT field is set to
RTPFB (205) and the FMT field is set to Port Mapping (7). Individual
Port Mapping messages are identified by a sub-field called Sub
Feedback Message Type (SFMT). Any Reserved field SHALL be set to
zero and ignored.
Following the rules specified in [RFC3550], all integer fields in the Following the rules specified in [RFC3550], all integer fields in the
messages defined below are carried in network-byte order, that is, messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian. most significant byte (octet) first, also known as big-endian.
Unless otherwise stated, numeric constants are in decimal (base 10). Unless otherwise stated, numeric constants are in decimal (base 10).
Note that RTCP is not a timely or reliable protocol. The RTCP Note that RTCP is not a timely or reliable protocol. The RTCP
packets might get lost or re-ordered in the network. When a client packets might get lost or re-ordered in the network. When sending a
sends a Port Mapping Request or Token Verification Request message new Port Mapping Request message, the scheduling rules that apply to
but it does not receive a response back from the server (either a sending initial RTCP messages [RFC4585] apply. When a client sends a
Port Mapping Response or Token Verification Failure message), it MAY Port Mapping Request or Token Verification Request message but it
resend its request when it is eligible to do so based on the timer does not receive a response back from the server (either a Port
rules defined in [RFC4585]. Mapping Response or Token Verification Failure message), it MAY
resend its request by following the timer rules defined for RTCP
feedback messages in Section 3.5 of [RFC4585] as a good practice.
When sending an RTCP (feedback) message bundled with a Token
Verification Request message, the timer rules of [RFC4585] apply as
usual.
4.1. Port Mapping Request 4.1. Port Mapping Request
The Port Mapping Request message is identified by SFMT=1. This The Port Mapping Request message is identified by SMT=1. This
message is a unicast feedback message transmitted by the client to a message is transmitted by the client to a dedicated server port (and
dedicated server port to request a Token. In the Port Mapping possibly an address) to request a Token. In the Port Mapping Request
Request message, the client MUST set both the packet sender SSRC and message, the packet sender SSRC is set to the client's SSRC. The
media source SSRC fields to its own SSRC since the Port Mapping packet format has the structure depicted in Figure 3.
Request message is not necessarily linked to any specific media
source. The FCI field has the structure depicted in Figure 4.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Random Nonce : |V=2|P| SMT=1 | PT=TOKEN=210 | Length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Random Nonce | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The FCI field of Port Mapping Request message Figure 3: Packet format for the Port Mapping Request message
o Random Nonce (56 bits): Mandatory field that contains a random o Random Nonce (64 bits): Mandatory field that contains a random
nonce value generated by the client following the procedures of nonce value generated by the client following the procedures of
[RFC4086]. This nonce is taken into account by the server when [RFC4086]. This nonce is taken into account by the server when
generating a Token for the client to enable better security for generating a Token for the client to enable better security for
clients that share the same IP address. If the Port Mapping clients that share the same IP address. If the Port Mapping
Request message is transmitted multiple times for redundancy Request message is transmitted multiple times for redundancy
reasons, the random nonce value MUST remain the same in these reasons, the random nonce value MUST remain the same in these
duplicated messages. However, the client MUST generate a new duplicated messages. However, the client MUST generate a new
random nonce for every new Port Mapping Request message. 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 SFMT=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 and media sender SSRC fields Response message, the packet sender SSRC is set to the server's SSRC.
are both set to the client's SSRC since the Port Mapping Response The packet format has the structure depicted in Figure 4.
message is not necessarily linked to any specific media source. The
FCI field has the structure depicted in Figure 5.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | Associated Nonce : |V=2|P| SMT=2 | PT=TOKEN=210 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Associated Nonce | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute | | Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time | | Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FCI field syntax for the Port Mapping Response message Figure 4: Packet format for the Port Mapping Response message
o Associated Nonce (56 bits): Mandatory field that contains the o SSRC of Requesting Client (32 bits): Mandatory field that
contains the SSRC of the client who sent the request.
o Associated Nonce (64 bits): Mandatory field that contains the
nonce received in the Port Mapping Request message and used in nonce received in the Port Mapping Request message and used in
Token construction. Token construction.
o Token Element (Variable size): Mandatory element that is used to o Token Element (Variable size): Mandatory element that is used to
carry the Token generated by the server. This element is a carry the Token generated by the server. This element is a
Length-Value element. The Length field, which is 8 bits, Length-Value element. The Length field, which is 8 bits,
indicates the length (in octets) of the Value field that follows indicates the length (in octets) of the Value field that follows
the Length field. The Value field carries the Token (or more the Length field. The Value field carries the Token (or more
accurately, the output of the encoding process on the server). accurately, the output of the encoding process on the server).
skipping to change at page 14, line 7 skipping to change at page 14, line 14
expiration time is expressed in seconds from the time the Token expiration time is expressed in seconds from the time the Token
was generated. A relative expiration time of zero indicates that was generated. A relative expiration time of zero indicates that
the accompanying Token is not valid. the accompanying Token is not valid.
The server conveys the relative expiration time in the clear to The server conveys the relative expiration time in the clear to
the client to allow the client to request a new Token well before the client to allow the client to request a new Token well before
the expiration time. the expiration time.
4.3. Token Verification Request 4.3. Token Verification Request
The Token Verification Request message is identified by SFMT=3. This The Token Verification Request message is identified by SMT=3. This
message contains the Token and accompanies any RTCP message that message contains the Token and accompanies any RTCP message that
would trigger a new or control an existing unicast session. would trigger a new or control an existing unicast session.
Currently, the following RTCP messages are REQUIRED to be accompanied Currently, the following RTCP messages are REQUIRED to be accompanied
by a Token Verification Request message: by a Token Verification Request message:
o Messages that trigger a new unicast session: o Messages that trigger a new unicast session:
* NACK messages [RFC4585] * NACK messages [RFC4585]
* RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp] * RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
skipping to change at page 14, line 36 skipping to change at page 14, line 43
* CCM messages [RFC5104] * CCM messages [RFC5104]
Other RTCP messages defined in the future, which could be abused to Other RTCP messages defined in the future, which could be abused to
cause packet amplification attacks, SHOULD also be authenticated cause packet amplification attacks, SHOULD also be authenticated
using the mechanism described in this document. The Token using the mechanism described in this document. The Token
Verification Request message might also be bundled with packets Verification Request message might also be bundled with packets
carrying RTCP receiver or extended reports. While such packets do carrying RTCP receiver or extended reports. While such packets do
not have a strong security impact, a specific application might not have a strong security impact, a specific application might
desire to have a more controlled reporting scheme from the clients. desire to have a more controlled reporting scheme from the clients.
In the Token Verification Request message, the client MUST set both In the Token Verification Request message, the packet sender SSRC is
the packet sender SSRC and media source SSRC fields to its own SSRC set to the client's SSRC. The client MUST NOT send a Token
since the media source SSRC may not be known. The client MUST NOT Verification Request message with a Token that has expired. The
send a Token Verification Request message with a Token that has packet format has the structure depicted in Figure 5.
expired. The FCI field has the structure depicted in Figure 6.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Associated Nonce : |V=2|P| SMT=3 | PT=TOKEN=210 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Associated Nonce | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token Element : : Token Element :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute | | Associated Absolute |
| Expiration Time | | Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the Token Verification message Figure 5: Packet format for the Token Verification Request message
o Associated Nonce (56 bits): Mandatory field that contains the o Associated Nonce (64 bits): Mandatory field that contains the
nonce associated with the Token above. nonce associated with the Token above.
o Token Element (Variable size): Mandatory Token element that was o Token Element (Variable size): Mandatory Token element that was
previously received in the Port Mapping Response message. previously received in the Port Mapping Response message.
o Associated Absolute Expiration Time (64 bits): Mandatory field o Associated Absolute Expiration Time (64 bits): Mandatory field
that contains the absolute expiration time associated with the that contains the absolute expiration time associated with the
Token above. Token above.
4.4. Token Verification Failure 4.4. Token Verification Failure
The Token Verification Failure message is identified by SFMT=4. This The Token Verification Failure message is identified by 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 and the Token Verification Failure message, the packet sender SSRC is set
media sender SSRC fields are both set to the client's SSRC. The FCI to the server's SSRC. The packet format has the structure depicted
field 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=4 | Associated Nonce : |V=2|P| SMT=4 | PT=TOKEN=210 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Associated Nonce | | SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Requesting Client |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FCI field syntax for the Token Failure message Figure 6: Packet format for the Token Verification Failure message
o Associated Nonce (56 bits): Mandatory field that contains the o SSRC of Requesting Client (32 bits): Mandatory field that
contains the SSRC of the client who sent the verification request.
o Associated Nonce (64 bits): Mandatory field that contains the
nonce received in the Token Verification Request message. If nonce received in the Token Verification Request message. If
there was no Token Verification Request message included by the there was no Token Verification Request message included by the
client, this field is set to 0. client, this field is set to 0.
5. Procedures for Token Construction 5. Procedures for Token Construction
The Token encoding is known to the server but opaque to the client. The Token encoding is known to the server but opaque to the client.
Implementations MUST encode the following information into the Token Implementations MUST encode the following information into the Token
as a minimum, in order to provide adequate security: as a minimum, in order to provide adequate security:
o Client's IP address as seen by the server (32/128 bits for IPv4/ o Client's IP address as seen by the server (32/128 bits for IPv4/
IPv6 addresses) IPv6 addresses)
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 (56 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 should be at least 160 bits long, and generated using a
cryptographically secure random source [RFC4086]. However, cryptographically secure random source [RFC4086]. However,
implementations MAY adopt different approaches and are encouraged to implementations MAY adopt different approaches and are encouraged to
skipping to change at page 20, line 21 skipping to change at page 20, line 21
that (i) a Token MUST be included in the feedback messages sent to that (i) a Token MUST be included in the feedback messages sent to
the server triggering or controlling a unicast session (See the server triggering or controlling a unicast session (See
Section 4.3 for details), and (ii) the client MUST receive the Section 4.3 for details), and (ii) the client MUST receive the
unicast session's RTP and RTCP packets from the server on the port unicast session's RTP and RTCP packets from the server on the port
from which it sent the RTCP message triggering or controlling the from which it sent the RTCP message triggering or controlling the
unicast session. unicast session.
The formal description of the 'portmapping-req' attribute is defined The formal description of the 'portmapping-req' attribute is defined
by the following ABNF [RFC5234] syntax: by the following ABNF [RFC5234] syntax:
portmapping-req-attribute = "a=portmapping-req:" [port [nettype space portmapping-req-attribute = "a=portmapping-req:" [port [SP nettype SP
addrtype space connection-address]] CRLF addrtype SP connection-address]] CRLF
Here, 'port', 'nettype', 'addrtype' and 'connection-address' are Here, 'port', 'nettype', 'addrtype' and 'connection-address' are
defined as specified in Section 9 of [RFC4566]. The 'portmapping- defined as specified in Section 9 of [RFC4566]. The 'portmapping-
req' attribute is used as a session-level or media-level attribute. req' attribute is used as a session-level or media-level attribute.
If used at a media level, the attribute MUST be used in a unicast If used at a media level, the attribute MUST be used in a unicast
media block. media block.
Note: This does not imply that Token Verification Request Note: This does not imply that Token Verification Request
messages need to be sent in the unicast session. Token messages need to be sent in the unicast session. Token
Verification Request messages accompany RTCP messages that trigger Verification Request messages accompany RTCP messages that trigger
skipping to change at page 22, line 31 skipping to change at page 22, line 31
i=Unicast Retransmission Stream i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=sendonly a=sendonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp-mux ; Note 4 a=rtcp-mux ; Note 4
a=rtcp:42500 ; Note 5 a=rtcp:42500 ; Note 5
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 6
a=mid:2 a=mid:2
Figure 8: 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
skipping to change at page 27, line 30 skipping to change at page 27, line 30
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: portmapping-req Attribute name: portmapping-req
Long form: Port for requesting Token Long form: Port for requesting Token
Type of name: att-field Type of name: att-field
Type of attribute: Either session or media level Type of attribute: Either session or media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: See this document
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: See this document Values: See this document
10.2. Registration of FMT Values 10.2. Registration of RTCP Control Packet Types
Within the RTPFB range, the following format (FMT) value is In accordance with Section 15 of [RFC3550], this specification adds
registered: the following value to the RTCP Control Packet types sub-registry of
the Real-Time Transport Protocol (RTP) Parameters registry:
Name: Port Mapping Value Abbrev. Name Reference
Long name: Port Mapping Between Unicast and Multicast RTP Sessions -------- --------- --------------------------------------- ---------
Value: 7 210 TOKEN Port Mapping [RFCXXXX]
Reference: [RFCXXXX]
10.3. SFMT Values for Port Mapping Messages Registry 10.3. SMT Values for TOKEN Packet Type Registry
This document creates a new sub-registry for the sub-feedback message This document creates a new sub-registry for the sub-message type
type (SFMT) values to be used with the FMT value registered for Port (SMT) values to be used with the TOKEN packet type. The registry is
Mapping messages. The registry is called the SFMT Values for Port called the SMT Values for TOKEN Packet Type Registry. This registry
Mapping Messages Registry. This registry is to be managed by the is to be managed by the IANA according to the Specification Required
IANA according to the Specification Required policy of [RFC5226]. policy of [RFC5226].
The length of the SFMT field in the Port Mapping messages is a single The length of the SMT field is five bits, allowing 32 values. The
octet, allowing 256 values. The registry is initialized with the registry is initialized with the following entries:
following entries:
Value Name Reference Value Name Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
0 Reserved [RFCXXXX] 0 Reserved [RFCXXXX]
1 Port Mapping Request [RFCXXXX] 1 Port Mapping Request [RFCXXXX]
2 Port Mapping Response [RFCXXXX] 2 Port Mapping Response [RFCXXXX]
3 Token Verification Request [RFCXXXX] 3 Token Verification Request [RFCXXXX]
4 Token Verification Failure [RFCXXXX] 4 Token Verification Failure [RFCXXXX]
5-254 Assignable - Specification Required 5-30 Assignable - Specification Required
255 Reserved [RFCXXXX] 31 Reserved [RFCXXXX]
The SFMT values 0 and 255 are reserved for future use. The SMT values 0 and 31 are reserved for future use.
Any registration for an unassigned SFMT value needs to contain the Any registration for an unassigned SMT value needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name and email.
o A detailed description of what the new SFMT represents and how it o A detailed description of what the new SMT represents and how it
shall be interpreted. shall be interpreted.
10.4. RAMS Response Code Space Registry 10.4. RAMS Response Code Space Registry
This document adds the following entry to the RAMS Response Code This document adds the following entry to the RAMS Response Code
Space Registry. Space Registry.
Code Description Reference Code Description Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
405 Invalid Token [RFCXXXX] 405 Invalid Token [RFCXXXX]
 End of changes. 47 change blocks. 
109 lines changed or deleted 113 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/