draft-ietf-avt-ports-for-ucast-mcast-rtp-05.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-06.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 5, 2011 T. VanCaenegem Expires: June 10, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
December 2, 2010 December 7, 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-05 draft-ietf-avt-ports-for-ucast-mcast-rtp-06
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 5, 2011. This Internet-Draft will expire on June 10, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 20 7.3. Example and Discussion . . . . . . . . . . . . . . . . . . 21
8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 23 8. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 24 9.2. The portmapping-req Attribute . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 26 10.1. Registration of SDP Attributes . . . . . . . . . . . . . . 26
10.2. Registration of FMT Values . . . . . . . . . . . . . . . . 26 10.2. Registration of FMT Values . . . . . . . . . . . . . . . . 26
10.3. SFMT Values for Port Mapping Messages Registry . . . . . . 26 10.3. SFMT Values for Port Mapping Messages Registry . . . . . . 26
10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 27 10.4. RAMS Response Code Space Registry . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 8, line 33 skipping to change at page 8, line 33
session. Port P4 is defined declaratively and MUST be different session. Port P4 is defined declaratively and MUST be different
from port P3. 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. However, there c1 and c2 MAY be the same port or different ports. There are two
are two advantages of using the same port for both c0 and c1: 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 retransmission requests
(or other traffic sent from the client to the server) is long, (or other traffic sent from the client to the server) is long,
this can exceed that timeout. If c0=c1, the occasional this can exceed that timeout. If c0=c1, the occasional
(periodic) RTCP receiver reports sent from port c0 (for the (periodic) RTCP receiver reports sent from port c0 (for the
multicast session's RTCP port P3) will ensure the NAT does not multicast session's RTCP port P3) will ensure the NAT does not
time out the public port associated with the incoming unicast time out the public port associated 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 Thus, it is strongly RECOMMENDED that the client uses the same
port for c0 and c1. 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 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 its
value MAY be the same for two or more unicast sessions sourced by value MAY be the same for two or more unicast sessions sourced by
the server. A Token once requested and retrieved by a client from the server. A Token once requested and retrieved by a client from
port PT remains valid until its expiration time. Port PT MAY be port PT remains valid until its expiration time. Port PT MAY be
equal to port P3. Port cT MAY also be equal to ports c0 and c1. 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: In addition to the ports, we use the following notation:
o DS: IP address of the distribution source o DS: IP address of the distribution source
skipping to change at page 20, line 9 skipping to change at page 20, line 9
Token is invalid. For applications using Token is invalid. For applications using
[I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new [I-D.ietf-avt-rapid-acquisition-for-rtp], this document defines a new
4xx-level response code in the RAMS Response Code Space Registry. A 4xx-level response code in the RAMS Response Code Space Registry. A
client that received a Token Verification Failure message can request client that received a Token Verification Failure message can request
a new Token from the server. a new Token from the server.
7. SDP Signaling 7. SDP Signaling
7.1. The portmapping-req Attribute 7.1. The portmapping-req Attribute
This new SDP attribute is used declaratively to indicate the port for This new SDP attribute is used declaratively to indicate the port and
obtaining a Token. Its presence indicates that a Token MUST be optionally the address for obtaining a Token. Its presence indicates
included in the feedback messages sent to the server triggering or that a Token MUST be included in the feedback messages sent to the
controlling a unicast session. server triggering or controlling a unicast session (See Section 4.3
for details).
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 CRLF portmapping-req-attribute = "a=portmapping-req:" port [nettype space
addrtype space connection-address] CRLF
Here, 'port' is defined as specified in Section 9 of [RFC4566]. The
'portmapping-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 media stream.
The Offer/Answer Model behavior [RFC3264] for the 'portmapping-req' Here, 'port', 'nettype', 'addrtype' and 'connection-address' are
attribute is not defined, thus, MUST NOT be used. This attribute defined as specified in Section 9 of [RFC4566]. The 'portmapping-
MUST only be used in a declarative manner. 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
media stream. 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.
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 22, line 11 skipping to change at page 22, line 17
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.
Note 6: The "a=portmapping-req" line indicates that a Token needs to Note 6: The "a=portmapping-req" line indicates that a Token needs to
be retrieved first before a unicast session associated to the be retrieved first before a unicast session associated to the
multicast session can be established and that the Port Mapping multicast session can be established and that the Port Mapping
Request message needs to be sent to port 30000 (PT). Request message needs to be sent to port 30000 (PT). Since there is
no address indiciated in this line, the client needs to retrieve the
Token from the address specified in the "c" line.
8. Address Pooling NATs 8. Address Pooling NATs
Large-scale NAT devices have a pool of public IPv4 addresses and map Large-scale NAT devices have a pool of public IPv4 addresses and map
internal hosts to one of those public IPv4 addresses. As long as an internal hosts to one of those public IPv4 addresses. As long as an
internal host maintains an active mapping in the NAT, the same IPv4 internal host maintains an active mapping in the NAT, the same IPv4
address is assigned to new connections. However, once all of the address is assigned to new connections. However, once all of the
host's mappings have been deleted (e.g., because of timeout), it is host's mappings have been deleted (e.g., because of timeout), it is
possible that a new connection from that same host will be assigned a possible that a new connection from that same host will be assigned a
different IPv4 address from the pool. When that occurs, the Token different IPv4 address from the pool. When that occurs, the Token
 End of changes. 12 change blocks. 
22 lines changed or deleted 37 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/