AVT A. Begen
Internet-Draft D. Wing
Intended status: Standards Track Cisco
Expires: February 13, 2011 T. VanCaenegem
Alcatel-Lucent
August 12, 2010
Token-Based Port Mapping Between Unicast and Multicast RTP Sessions
draft-begen-avt-token-for-portmapping-01
Abstract
This document presents an alternative port mapping solution that
allows RTP receivers to choose their own ports for an auxiliary
unicast session in RTP applications using both unicast and multicast
services (almost) without the need for retrieving pre-authorization.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 13, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Begen, et al. Expires February 13, 2011 [Page 1]
Internet-Draft Token-Based Port Mapping August 2010
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Token-Based Port Mapping . . . . . . . . . . . . . . . . . . . 5
3.1. Token Request and Retrieval . . . . . . . . . . . . . . . 5
3.2. Unicast Session Establishment . . . . . . . . . . . . . . 5
4. The portmapping-req Attribute . . . . . . . . . . . . . . . . 9
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10
6. Procedures for Token Construction . . . . . . . . . . . . . . 11
7. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 12
8. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Begen, et al. Expires February 13, 2011 [Page 2]
Internet-Draft Token-Based Port Mapping August 2010
1. Introduction
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] provides several scenarios
for RTP applications that use one or more unicast and multicast RTP
sessions together. These applications require a Port Mapping
solution that allows receivers to choose their desired UDP ports for
RTP and RTCP in unicast session(s). There is an inherent delay in
learning the public port mapping and signaling it with the Offer/
Answer Model [RFC3264]. Thus, the receiver might wish to convey its
port number(s) through a different mechanism.
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] offers a Cookie-based
solution. This memo presents a more lightweight solution, which we
call the Token solution.
Following the same convention with
[I-D.ietf-avt-ports-for-ucast-mcast-rtp], we will refer to the RTP
endpoints that serve other RTP endpoints over a unicast session as
the Servers, and the receiving RTP endpoints as Clients.
Begen, et al. Expires February 13, 2011 [Page 3]
Internet-Draft Token-Based Port Mapping August 2010
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Begen, et al. Expires February 13, 2011 [Page 4]
Internet-Draft Token-Based Port Mapping August 2010
3. Token-Based Port Mapping
Token-based Port Mapping consists of two steps: Token request and
retrieval, and unicast session establishment. These are described in
the following sections.
3.1. Token Request and Retrieval
The first step is required to be completed only once. Once a Token
is retrieved from a particular server, it may be used for all the
unicast sessions the client will be running with this particular
server. By default, Tokens are server specific. However, the client
can use the same Token to communicate with different servers if these
servers are provided with the same key used to generate the Token.
The Token may become invalid if client's public IP address changes or
when the server expires the token. In those cases, the client has to
request a new Token.
The Token is essentially an opaque encapsulation that conveys
client's IP address information (as seen by the server) using a
reversible transform only known to the server. When a request is
received, the server creates a Token for this particular client, and
sends it back to the client. Later, when the client wants to
establish a unicast session, the Token will be validated by the
server, making sure that the IP address information matches. This is
effective against DoS attacks, i.e., an attacker cannot simply spoof
another client's IP address and start possibly a high-bitrate unicast
transmission [I-D.ietf-avt-rapid-acquisition-for-rtp] towards random
clients.
3.2. Unicast Session Establishment
We illustrate the second step on the same example presented in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp].
Consider an SSM distribution network where a distribution source
multicasts RTP packets to a large number of clients, and one or more
retransmission servers function as feedback targets to collect
unicast RTCP feedback from these clients [RFC5760]. The
retransmission servers also join the primary multicast session to
receive the multicast packets and cache them for a certain time
period. When a client detects missing packets in the primary
multicast session, it requests a retransmission from one of the
retransmission servers by using an RTCP NACK message [RFC4585]. The
retransmission server pulls the requested packet(s) out of the cache
and retransmits them to the requesting client [RFC4588].
The pertaining RTP and RTCP flows are sketched in Figure 1. Between
Begen, et al. Expires February 13, 2011 [Page 5]
Internet-Draft Token-Based Port Mapping August 2010
the client and server, there may be one or more NAT devices
[RFC4787].
-------------- --- ----------
| |-------------------------------| |-->|P1 |
| |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-| |.->|P2 |
| | | | | |
| Distribution | ---------------- | | | |
| Source | | | | | | |
| |---->|P1 | | | | |
| |.-.->|P2 | | | | |
| | | | | | | |
-------------- | P3|<.=.=.=.| |=.=|*c0 |
| P3|<~~~~~~~| |~~~|*c1 |
PRIMARY MULTICAST | | | | | |
RTP SESSION with | | | | | |
UNICAST FEEDBACK | | | N | | |
| Retransmission | | A | | Client |
- - - - - - - - - - -| - - - - - - - -| - - - -| - |- -| - - - - -|-
| Server | | T | | |
AUXILIARY UNICAST | | | | | |
RTP SESSION | | | | | |
| P3|........| |..>|*c1 |
| P3|=.=.=.=.| |=.>|*c1 |
| P4|<.=.=.=.| |=.=|*c2 |
| | | | | |
---------------- --- ----------
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow
Figure 1: Example scenario showing an SSM distribution with support
for retransmissions from a server
In this figure, we have the following multicast and unicast ports:
o Ports P1 and P2 denote the destination RTP and RTCP ports in the
primary multicast session, respectively. The clients listen to
these ports to receive the multicast RTP and RTCP packets. Ports
P1 and P2 are defined declaratively.
o Port P3 denotes the RTCP port on the feedback target running on
the retransmission server to collect the RTCP feedback messages,
Begen, et al. Expires February 13, 2011 [Page 6]
Internet-Draft Token-Based Port Mapping August 2010
and RTCP receiver and extended reports from the clients in the
primary multicast session. This is also the port that the
retransmission server uses to send the RTP packets and RTCP sender
reports in the unicast session. Port P3 is defined declaratively.
o Port P4 denotes the RTCP port on the retransmission server used to
collect the RTCP receiver and extended reports for the unicast
session. Port P4 is defined declaratively and MUST be different
from port P3.
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 primary
multicast session. *c1 denotes the port on the client used to send
the unicast RTCP feedback in the primary multicast session and to
receive the RTP packets and RTCP sender reports in the unicast
session. *c2 denotes the port on the client used to send the RTCP
receiver and extended reports in the unicast session. Ports c0,
c1 and c2 MAY be the same port or different ports. However, there
are two advantages of using the same port for both c0 and c1:
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
of [RFC4787]). Long RTP bursts may exceed that timeout. If
c0=c1, the occasional RTCP receiver reports sent from port c0
will ensure the NAT does not time out the public port
associated with the incoming RTP burst to port c1.
2. Having c0=c1 conserves NAT port bindings.
Thus, it is strongly RECOMMENDED that c0=c1.
Once the server receives the RTCP NACK, the server sends the RTP
burst to the IP address and UDP port the RTCP NACK came from.
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
part of the session description information and is provided to the
Begen, et al. Expires February 13, 2011 [Page 7]
Internet-Draft Token-Based Port Mapping August 2010
clients. The Session Description Protocol (SDP) [RFC4566] and other
session description methods can be used for this purpose.
The following steps summarize the Token-based solution:
1. The client ascertains server address (S) and port numbers (P3 and
P4) from the session description.
2. The client determines its port numbers (*c0, *c1 and *c2).
3. If the client does not have a valid Token for this particular
server:
A. The client first sends a message to the server via a new RTCP
message, called PortMappingRequest. This message can be sent
from any port on the client side. The server learns client's
public IP address (C') from the received message.
NOTE: The client can send this message anytime it wants
(e.g., during initialization), and does not normally ever
need to re-send this message (See Section 7).
B. The server generates an opaque encapsulation (called Token)
that conveys client's IP address information using a
reversible transform only known to the server. See
Section 6.
C. The server sends the Token back to the client using a new
RTCP message, called PortMappingResponse. This message MUST
be sent from the port at which the server received the
request.
4. The client includes the Token when necessary in the subsequent
messages sent to the server. Note that the unicast session is
only established after the server has received a feedback message
(along with a valid Token) from the client for which it needs to
react by sending unicast data. Until a unicast session is
established, neither the server nor the client needs to send RTCP
reports for the unicast session.
5. Normal flows ensue as shown in Figure 1. If the client uses the
same port for both c0 and c1, the RTCP receiver and extended
reports sent for the primary multicast session keep the P3->c1
binding alive. If the client uses different ports for c0 and c1,
an explicit keep-alive message [I-D.ietf-avt-app-rtp-keepalive]
may be needed to keep the P3->c1 binding alive during the
lifetime of the unicast session, if that unicast session's
lifetime exceeds the NAT's mapping refresh time.
Begen, et al. Expires February 13, 2011 [Page 8]
Internet-Draft Token-Based Port Mapping August 2010
4. The portmapping-req Attribute
This new SDP attribute is used declaratively to indicate the port for
obtaining a Token. Its presence also indicates that a Token MUST be
included in the feedback messages sent to the server.
The formal description of the 'portmapping-req' attribute is defined
by the following ABNF [RFC5234] syntax:
portmapping-req-attribute = "a=portmapping-req:" port CRLF
Here, the 'port' token is defined as specified in Section 9 of
[RFC4566].
The 'portmapping-req' attribute MAY be used as a media-level
attribute; it MUST NOT be used as a session-level attribute.
Begen, et al. Expires February 13, 2011 [Page 9]
Internet-Draft Token-Based Port Mapping August 2010
5. Message Formats
Editor's note: This section will define the message formats for
requesting a Token (PortMappingRequest) and sending a Token
(PortMappingResponse).
TBC.
Begen, et al. Expires February 13, 2011 [Page 10]
Internet-Draft Token-Based Port Mapping August 2010
6. Procedures for Token Construction
Editor's notes:
The Token may contain
o Client's IP address
o A timestamp to protect against replay attacks
o HMAC [RFC2104] of the above information (where only the server
knows the HMAC secret)
The server conveys the expiration date in the clear to the client via
the PortMappingResponse message. Thus, the client can request a new
Token before the current one expires.
Details are TBC.
Begen, et al. Expires February 13, 2011 [Page 11]
Internet-Draft Token-Based Port Mapping August 2010
7. Validating Tokens
Upon receipt of an RTCP feedback message containing a Token, the
server validates the Token. The server considers a Token valid if
the source IP address of the RTCP feedback message matches the IP
address in the Token, and if the Token has not expired.
The IP address is encoded into the Token by the server, using an
algorithm known only to the server. This, combined with the
expiration, provides protection against DoS attacks so that a client
using a certain IP address cannot cause one or more RTP packets to be
sent to another client with a different IP address.
Begen, et al. Expires February 13, 2011 [Page 12]
Internet-Draft Token-Based Port Mapping August 2010
8. SDP Example
The SDP describing the scenario given in Figure 1 can be written as:
v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 ; Note 1
a=rtpmap:98 MP2T/90000s
a=multicast-rtcp:41500 ; Note 1
a=rtcp:42000 IN IP4 192.0.2.1 ; Note 2
a=rtcp-fb:98 nack ; Note 2
a=mid:1
m=video 42000 RTP/AVPF 99 ; Note 3
i=Unicast Retransmission Stream
c=IN IP4 192.0.2.1
a=rtpmap:99 rtx/90000
a=rtcp:42500 ; Note 4
a=fmtp:99 apt=98; rtx-time=5000
a=portmapping-req:30000 ; Note 5
a=mid:2
Figure 2: SDP describing an SSM distribution with support for
retransmissions from a local server
In this SDP, we highlight the following notes:
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
destination address of 233.252.0.2 (G) and port 41000 (P1). The
associated RTCP packets are multicast in the same group to port 41500
(P2).
Note 2: A retransmission server including feedback target
functionality with an IP address of 192.0.2.1 (S) and port of 42000
(P3) is specified with the 'rtcp' attribute. The feedback
functionality is enabled for the RTP stream with payload type 98
through the 'rtcp-fb' attribute [RFC4585].
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
not send any RTP traffic back to the server. To make this clear, we
Begen, et al. Expires February 13, 2011 [Page 13]
Internet-Draft Token-Based Port Mapping August 2010
might mandate to use the discard port in this line.
Note 4: The server uses port 42500 (P4) for the unicast sessions.
Note 5: The "a=portmapping-req" line indicates that a Token MUST be
retrieved first before a unicast session can be established and that
the Token request MUST be sent to port 30000.
Begen, et al. Expires February 13, 2011 [Page 14]
Internet-Draft Token-Based Port Mapping August 2010
9. Address Pooling NATs
Large-scale NAT (LSN) devices have a pool of public IPv4 addresses
and map 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 address is assigned to new connections. However, once all
of the 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 different IPv4 address from the pool. When that occurs,
the Token will be considered invalid by the server, causing an
additional round trip for the client to acquire a fresh token.
Any traffic from the host which traverses the NAT will prevent this
problem. As the host is sending RTCP receiver reports at least every
5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is
receiving, those RTCP messages will be sufficient to prevent this
problem.
Begen, et al. Expires February 13, 2011 [Page 15]
Internet-Draft Token-Based Port Mapping August 2010
10. Security Considerations
The Token, which is generated based on a client's IP address and
expiration date, provides protection against DoS attacks. An
attacker using a certain IP address cannot cause one or more RTP
packets to be sent to a victim client who has a different IP address.
Begen, et al. Expires February 13, 2011 [Page 16]
Internet-Draft Token-Based Port Mapping August 2010
11. IANA Considerations
The following contact information shall be used for all registrations
in this document:
Ali Begen
abegen@cisco.com
11.1. Registration of SDP Attributes
This document registers a new attribute name in SDP.
SDP Attribute ("att-field"):
Attribute name: portmapping-req
Long form: Port for requesting Token
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: See this document
Begen, et al. Expires February 13, 2011 [Page 17]
Internet-Draft Token-Based Port Mapping August 2010
12. Acknowledgments
The approach presented in this document came out after discussions
with various individuals in the AVT and MMUSIC WGs, and the breakout
session held in the Anaheim meeting. We thank each of these
individuals.
Begen, et al. Expires February 13, 2011 [Page 18]
Internet-Draft Token-Based Port Mapping August 2010
13. References
13.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions",
draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), May 2010.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-11 (work in
progress), July 2010.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
Begen, et al. Expires February 13, 2011 [Page 19]
Internet-Draft Token-Based Port Mapping August 2010
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[I-D.ietf-avt-app-rtp-keepalive]
Marjou, X. and A. Sollaud, "Application Mechanism for
keeping alive the Network Address Translator (NAT)
mappings associated to RTP flows.",
draft-ietf-avt-app-rtp-keepalive-08 (work in progress),
June 2010.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
Begen, et al. Expires February 13, 2011 [Page 20]
Internet-Draft Token-Based Port Mapping August 2010
Authors' Addresses
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
Email: abegen@cisco.com
Dan Wing
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
USA
Email: dwing@cisco.com
Tom VanCaenegem
Alcatel-Lucent
Copernicuslaan 50
Antwerpen, 2018
Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.be
Begen, et al. Expires February 13, 2011 [Page 21]