draft-ietf-avt-ports-for-ucast-mcast-rtp-06.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-07.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 10, 2011 T. VanCaenegem Expires: June 13, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
December 7, 2010 December 10, 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-06 draft-ietf-avt-ports-for-ucast-mcast-rtp-07
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 10, 2011. This Internet-Draft will expire on June 13, 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 16 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6 3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 6
3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 6 3.1. 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 . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 21 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 21
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 23 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 24 9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 26 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 27
10.2. Registration of FMT Values . . . . . . . . . . . . . . . . 26 10.2. Registration of FMT Values . . . . . . . . . . . . . . . . 27
10.3. SFMT Values for Port Mapping Messages Registry . . . . . . 26 10.3. SFMT Values for Port Mapping Messages Registry . . . . . . 27
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 27 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
In (any-source or source-specific) multicast RTP applications, In (any-source or source-specific) multicast RTP applications,
destination ports, i.e., the ports on which the multicast receivers destination ports, i.e., the ports on which the multicast receivers
receive the RTP and RTCP packets, are defined declaratively. In receive the RTP and RTCP packets, are defined declaratively. In
other words, the receivers cannot choose their receive ports and the other words, the receivers cannot choose their receive ports and the
sender(s) use the pre-defined ports. sender(s) use the pre-defined ports.
In unicast RTP applications, the receiving end needs to choose its In unicast RTP applications, the receiving end needs to choose its
skipping to change at page 8, line 5 skipping to change at page 7, line 48
-------> 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
3.2.2. Normative Behavior and Requirements
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
P2 are defined declaratively. P2 are defined declaratively.
o Port P3 denotes the RTCP port on the feedback target running on o Port P3 denotes the RTCP port on the feedback target running on
the retransmission server to collect any RTCP packet sent by the the retransmission server to collect any RTCP packet sent by the
clients including feedback messages, and RTCP receiver and clients including feedback messages, and RTCP receiver and
extended reports. This is also the port that the retransmission extended reports. This is also the port that the retransmission
server uses to send the RTP packets and RTCP sender reports in the server uses to send the RTP packets and RTCP sender reports in the
unicast session. Port P3 is defined declaratively. unicast session. Port P3 is defined declaratively.
o Port P4 denotes the RTCP port on the retransmission server used to o Port P4 denotes the RTCP port on the retransmission server used to
collect the RTCP receiver and extended reports for the unicast collect the RTCP receiver and extended reports for the unicast
session. Port P4 is defined declaratively and MUST be different session. Port P4 is defined declaratively.
from port P3.
o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the o Ports *c0, *c1 and *c2 are chosen by the client. *c0 denotes the
port on the client used to send the RTCP reports for the multicast port on the client used to send the RTCP reports for the multicast
session. *c1 denotes the port on the client used to send the session. *c1 denotes the port on the client used to send the
unicast RTCP feedback messages in the multicast session and to unicast RTCP feedback messages in the multicast session and to
receive the RTP packets and RTCP sender reports in the unicast receive the RTP packets and RTCP sender reports in the unicast
session. *c2 denotes the port on the client used to send the RTCP session. *c2 denotes the port on the client used to send the RTCP
receiver and extended reports in the unicast session. Ports c0, receiver and extended reports in the unicast session. Ports c0,
c1 and c2 MAY be the same port or different ports. There are two c1 and c2 could be the same port or different ports. There are
advantages of using the same port for both c0 and c1: two advantages of using the same port for both c0 and c1:
1. Some NATs only keep bindings active when a packet goes from 1. Some NATs only keep bindings active when a packet goes from
the inside to the outside of the NAT (See REQ-6 of Section 4.3 the inside to the outside of the NAT (See REQ-6 of Section 4.3
of [RFC4787]). When the gap between retransmission requests of [RFC4787]). When the gap between the packets sent from the
(or other traffic sent from the client to the server) is long, client to the server is long, this can exceed that timeout.
this can exceed that timeout. If c0=c1, the occasional If c0=c1, the occasional (periodic) RTCP receiver reports sent
(periodic) RTCP receiver reports sent from port c0 (for the from port c0 (for the multicast session's RTCP port P3) will
multicast session's RTCP port P3) will ensure the NAT does not ensure the NAT does not time out the public port associated
time out the public port associated with the incoming unicast with the incoming unicast traffic to port c1.
traffic to port c1.
2. Having c0=c1 conserves NAT port bindings. 2. Having c0=c1 conserves NAT port bindings.
Thus, it is strongly RECOMMENDED that the client uses the same o Ports PT and *cT denote the ports through which the Token request
port for c0 and c1.
A client cannot keep using the same receive port for different
unicast sessions since there could be packet leakage when
switching from one unicast session to another unless each received
unicast stream has its own distinct Synchronization Source (SSRC)
identifier to allow the client to filter out the undesired
packets. Unless this is guaranteed (which is not often easy), a
client SHOULD use separate receive ports for subsequent unicast
sessions. After a sufficient time, a previously used receive port
could be used again.
o Ports PT and cT denote the ports through which the Token request
and retrieval occur at the server and client sides, respectively. and retrieval occur at the server and client sides, respectively.
Port PT is declared on a per unicast session basis, although its Port PT is declared on a per unicast session basis, although the
value MAY be the same for two or more unicast sessions sourced by same port could be used for two or more unicast sessions sourced
the server. A Token once requested and retrieved by a client from by the server. A Token once requested and retrieved by a client
port PT remains valid until its expiration time. Port PT MAY be from port PT remains valid until its expiration time.
equal to port P3. Port cT MAY also be equal to ports c0 and c1.
In addition to the ports, we use the following notation:
o DS: IP address of the distribution source
o G: Destination multicast address
o S: IP address of the retransmission server
o C: IP address of the client
o C': Public IP address of the client (as seen by the server)
We assume that the information declaratively defined is available as We assume that the information declaratively defined is available as
part of the session description information and is provided to the part of the session description information and is provided to the
clients. The Session Description Protocol (SDP) [RFC4566] and other clients. The Session Description Protocol (SDP) [RFC4566] and other
session description methods can be used for this purpose. session description methods can be used for this purpose.
3.2.2. Normative Behavior and Requirements
In this section, we describe the normative behavior and requirements.
To simplify the presentation, we refer to the port numbers described
in the example presented in Figure 2. However, the behavior and
requirements described here are not specific to that particular
example.
The following steps summarize the Token-based solution: The following steps summarize the Token-based solution:
1. The client ascertains server address (S) and port numbers (P3 and 1. The client ascertains server address and port numbers (P3, P4 and
P4) from the session description. PT) from the session description. Port P4 MUST be different from
port P3. Port PT MAY be equal to port P3.
2. The client selects its local port numbers (*c0, *c1 and *c2). 2. The client selects its local port numbers (*c0, *c1, *c2 and
*cT). It is strongly RECOMMENDED that the client uses the same
port for c0 and c1. Port cT MAY be equal to ports c0 and c1.
A client cannot keep using the same receive port for different
unicast sessions since there could be packet leakage when
switching from one unicast session to another unless each
received unicast stream has its own distinct Synchronization
Source (SSRC) identifier to allow the client to filter out the
undesired packets. Unless this is guaranteed (which is not often
easy), a client SHOULD use separate receive ports for subsequent
unicast sessions. After a sufficient time, a previously used
receive port could be used again.
3. If the client does not have a Token (or the existing Token has 3. If the client does not have a Token (or the existing Token has
expired): expired):
A. The client first sends a message to the server via a new RTCP A. The client first sends a message to the server via a new RTCP
message, called Port Mapping Request to port PT. This message, called Port Mapping Request to port PT. This
message is sent from port cT on the client side. The server message is sent from port *cT on the client side. The server
learns client's public IP address (C') from the received learns client's public IP address from the received message.
message. The client can send this message anytime it wants The client can send this message anytime it wants (e.g.,
(e.g., during initialization), and does not normally ever during initialization), and does not normally ever need to
need to re-send this message (See Section 6). re-send this message (See Section 6).
B. The server generates an opaque encapsulation (i.e., the B. The server generates an opaque encapsulation (i.e., the
Token) based on certain information including client's IP Token) based on certain information including client's IP
address. address.
C. The server sends the Token back to the client using a new C. The server sends the Token back to the client using a new
RTCP message, called Port Mapping Response. This message RTCP message, called Port Mapping Response. This message
MUST be sent from port PT to port cT. MUST be sent from port PT to port cT.
4. The client needs to provide the Token to the server using a new 4. The client needs to provide the Token to the server using a new
skipping to change at page 20, line 11 skipping to change at page 20, line 11
4xx-level response code in the RAMS Response Code Space Registry. A 4xx-level response code in the RAMS Response Code Space Registry. A
client that received a Token Verification Failure message can request client that received a Token Verification Failure message can request
a new Token from the server. a new Token from the server.
7. SDP Signaling 7. SDP Signaling
7.1. The portmapping-req Attribute 7.1. The portmapping-req Attribute
This new SDP attribute is used declaratively to indicate the port and This new SDP attribute is used declaratively to indicate the port and
optionally the address for obtaining a Token. Its presence indicates optionally the address for obtaining a Token. Its presence indicates
that a Token MUST be included in the feedback messages sent to the that (i) a Token MUST be included in the feedback messages sent to
server triggering or controlling a unicast session (See Section 4.3 the server triggering or controlling a unicast session (See
for details). 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
from which it sent the RTCP message triggering or controlling the
unicast session.
The formal description of the 'portmapping-req' attribute is defined The formal description of the 'portmapping-req' attribute is defined
by the following ABNF [RFC5234] syntax: by the following ABNF [RFC5234] syntax:
portmapping-req-attribute = "a=portmapping-req:" port [nettype space portmapping-req-attribute = "a=portmapping-req:" [port [nettype space
addrtype space connection-address] CRLF addrtype space 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 for a unicast If used at a media level, the attribute MUST be used in a unicast
media stream. In the optional address value, only unicast addresses media block.
are allowed; multicast addresses SHOULD NOT be used without
evaluating the additional security risks such as non-legit servers Note: This does not imply that Token Verification Request
generating fake Tokens. If the address is not specified, the messages need to be sent in the unicast session. Token
(source) address in the "c" line corresponding to the unicast media Verification Request messages accompany RTCP messages that trigger
stream is implied. or control this unicast session, and are sent either in the
multicast session or the unicast session, depending on the RTCP
message (See Section 4.3).
In the optional address value, only unicast addresses are allowed;
multicast addresses SHOULD NOT be used without evaluating the
additional security risks such as non-legit servers generating fake
Tokens. If the address is not specified, the (source) address in the
"c" line corresponding to the unicast media stream is implied.
When using this SDP attribute in SDP offer/answer [RFC3264], the
following needs to be considered. This attribute is used
declaratively. If included at session level, this applies to all
media lines that uses RTP. If included at media level, it applies to
the RTCP feedback messages declared by this media block.
An offerer that desires the answerer to use Tokens in any RTCP
message sent to the offerer, i.e., received by the offerer, the
attribute is included. In case an offerer desires to declare support
for using Tokens as defined in this specification but do not need
Tokens to be included for any RTCP messages to be received by the
offerer, it can include the 'portmapping-req' attribute without any
parameters, neither port nor address, either at a session or media
level.
An answerer receiving an SDP offer with the "a=portmapping-req" line
with a port number SHALL use that port number and the address, either
explicitly provided in the attribute or implicitly provided by the
"c" line, for any needed Token request. If the "a=portmapping-req"
line attribute does not contain a port, the answer SHALL take note of
the capability.
When sending an answer, if the 'portmapping-req' attribute has been
present in the offer including a port number and the answerer
supports this specification, then the answerer MUST include the
attribute in its answer. The answer may or may not include a port
and address. This depends on the application and the desire of the
answerer. The answerer includes a port and possibly an address when
it requires to receive Tokens in RTCP messages. If it only supports
this specification but does not need Tokens to be included, the
attribute is included without any port or address.
7.2. Requirements 7.2. Requirements
The use of SDP for the port mapping solution normatively requires the The use of SDP for the port mapping solution normatively requires the
support for: support for:
o The SDP grouping framework and flow identification (FID) semantics o The SDP grouping framework and flow identification (FID) semantics
[RFC5888] [RFC5888]
o The RTP/AVPF profile [RFC4585] o The RTP/AVPF profile [RFC4585]
skipping to change at page 21, line 42 skipping to change at page 22, line 37
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 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 (DS) to the multicast with a source IP address of 198.51.100.1 to the multicast destination
destination address of 233.252.0.2 (G) and port 41000 (P1). The address of 233.252.0.2 and port 41000 (P1). The associated RTCP
associated RTCP packets are multicast in the same group to port 41500 packets are multicast in the same group to port 41500 (P2).
(P2).
Note 2: A retransmission server including feedback target Note 2: A retransmission server including feedback target
functionality with an IP address of 192.0.2.1 (S) and port of 42000 functionality with an IP address of 192.0.2.1 and port of 42000 (P3)
(P3) is specified with the 'rtcp' attribute. The feedback is specified with the 'rtcp' attribute. The feedback functionality
functionality is enabled for the RTP stream with payload type 98 is enabled for the RTP stream with payload type 98 through the
through the 'rtcp-fb' attribute [RFC4585]. 'rtcp-fb' attribute [RFC4585].
Note 3: The port specified in the second "m" line (for the unicast Note 3: The port specified in the second "m" line (for the unicast
stream) does not mean anything in this scenario as the client does stream) does not mean anything in this scenario as the client does
not send any RTP traffic back to the server. not send any RTP traffic back to the server.
Note 4: The server multiplexes RTP and RTCP packets on the same port Note 4: The server multiplexes RTP and RTCP packets on the same port
(c1 in Figure 2). (c1 in Figure 2).
Note 5: The server uses port 42500 (P4) for the unicast sessions. Note 5: The server uses port 42500 (P4) for the unicast sessions.
 End of changes. 22 change blocks. 
92 lines changed or deleted 125 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/