draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00.txt   draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01.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: August 1, 2011 T. VanCaenegem Expires: September 14, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
January 28, 2011 March 13, 2011
Port Mapping Between Unicast and Multicast RTP Sessions Port Mapping Between Unicast and Multicast RTP Sessions
draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01
Abstract Abstract
This document presents a port mapping solution that allows RTP This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services. The in RTP applications using both unicast and multicast services. The
solution provides protection against denial-of-service or packet solution provides protection against denial-of-service or packet
amplification attacks that could be used to cause one or more RTP amplification attacks that could be used to cause one or more RTP
packets to be sent to a victim client. packets to be sent to a victim client.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2011. This Internet-Draft will expire on September 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 10, line 11 skipping to change at page 10, line 11
In this section, we describe the 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 To simplify the presentation, we refer to the port numbers described
in the example presented in Figure 2. However, the behavior and in the example presented in Figure 2. However, the behavior and
requirements described here are not specific to that particular requirements described here are not specific to that particular
example, and can be applied to any scenario where analogous ports can example, and can be applied to any scenario where analogous ports can
be identified. be identified.
First of all, a client compliant with this specification MUST be able First of all, a client compliant with this specification MUST be able
to include a Token with any type of RTCP message (as described below) to include a Token with any type of RTCP message (as described below)
when it is needed. That is, clients MUST NOT implement this when it is needed.
specification with only a specific use case in mind.
Second, the solution provided in this specification is not applicable Second, the solution provided in this specification is not applicable
in cases where there is RTP traffic flowing from the client to the in cases where there is RTP traffic flowing from the client to the
server in the unicast session. In other words, the direction of RTP server in the unicast session. In other words, the direction of RTP
traffic MUST be only from the server to the client in the unicast traffic MUST be only from the server to the client in the unicast
session. If the client wants to send RTP traffic back to the server, session. If the client wants to send RTP traffic back to the server,
the regular session establishment methods such as [RFC3264] need to the regular session establishment methods such as [RFC3264] need to
be used. be used.
The following steps summarize the Token-based solution: The following steps summarize the Token-based solution:
skipping to change at page 11, line 19 skipping to change at page 11, line 15
missing, the server sends a Token Verification Failure message missing, the server sends a Token Verification Failure message
(Section 4.4) to the client. (Section 4.4) to the client.
Note that the unicast session is only established after the Note that the unicast session is only established after the
server has received a feedback message (along with a valid Token) server has received a feedback message (along with a valid Token)
from the client for which it needs to react by sending unicast from the client for which it needs to react by sending unicast
data. Until a unicast session is established, neither the server data. Until a unicast session is established, neither the server
nor the client needs to send RTCP reports for the unicast nor the client needs to send RTCP reports for the unicast
session. session.
5. Normal flows ensue as shown in Figure 2. Note that in the 5. Normal flows ensue as shown in Figure 2. It is strongly
unicast session, traffic from the server to the client (i.e., RECOMMENDED that the client uses the same port for both c0 and
both the RTP and RTCP packets sent from port P3 towards port c1) c1, as this causes the periodic RTCP reports to keep the NAT
MUST be multiplexed on the (same) port c1. If the client uses mapping alive. However, if the client uses different ports for
the same port for both c0 and c1, the RTCP reports sent for the c0 and c1, the client MUST keep its own NAT mapping alive for the
multicast session keep the P3->c1(=c0) binding alive. If the P3->c1 session (See [I-D.ietf-avt-app-rtp-keepalive] for
client uses different ports for c0 and c1, the client needs to additional information).
periodically send an explicit keep-alive message
[I-D.ietf-avt-app-rtp-keepalive] to keep the P3->c1 binding alive In the unicast session, traffic from the server to the client
during the lifetime of the unicast session if the time between (i.e., both the RTP and RTCP packets sent from port P3 towards
unicast feedback messages (from c1 to P3) is likely to exceed the port c1) MUST be multiplexed on the (same) port c1.
NAT's timeout value (For the NAT timeout value requirements, see
[RFC4787]).
The client sends the RTCP receiver and extended reports in the The client sends the RTCP receiver and extended reports in the
unicast session from port c2 towards port P4. The server unicast session from port c2 towards port P4. The server
correlates these reports with the reports received in the correlates these reports with the reports received in the
multicast session based on the client's RTCP Canonical Name multicast session based on the client's RTCP Canonical Name
(CNAME). Thus, the client MUST use the same RTCP CNAME in both (CNAME). Thus, the client MUST use the same RTCP CNAME in both
sessions and its RTCP CNAME MUST be unique sessions and its RTCP CNAME MUST be unique
[I-D.ietf-avt-rtp-cnames]. [I-D.ietf-avt-rtp-cnames].
A unicast session on a particular receive port c1 can last as long as A unicast session on a particular receive port c1 can last as long as
skipping to change at page 14, line 32 skipping to change at page 14, line 32
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Packet format for the Port Mapping Request message Figure 3: Packet format for the Port Mapping Request message
o Random Nonce (64 bits): Field that contains a random value o Random Nonce (64 bits): Field that contains a random value
generated by the client following the procedures of [RFC4086]. generated by the client following the procedures of [RFC4086].
This nonce is taken into account by the server when generating a This nonce is taken into account by the server when generating a
Token for the client to enable better security for clients that Token for the client to enable better security for clients that
share the same IP address (Such clients need to produce a random share the same IP address (Such clients need to produce a random
value guaranteed to be temporally and globally unique). If the value extremely unlikely to collide with other clients sharing the
same Port Mapping Request message is transmitted multiple times same IP address). If the same Port Mapping Request message is
for redundancy reasons, the random nonce value MUST remain the transmitted multiple times for redundancy reasons, the random
same in these duplicated messages. However, the client MUST nonce value MUST remain the same in these duplicated messages.
generate a new random nonce for every new Port Mapping Request However, the client MUST generate a new random nonce for every new
message. Port Mapping Request message.
4.2. Port Mapping Response 4.2. Port Mapping Response
The Port Mapping Response message is identified by SMT=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 is set to the server's SSRC. Response message, the packet sender SSRC is set to the server's SSRC.
The packet format has the structure depicted in Figure 4. The packet format has the structure depicted in Figure 4.
0 1 2 3 0 1 2 3
skipping to change at page 18, line 20 skipping to change at page 18, line 20
authenticated by using a Token. Such messages include but are not authenticated by using a Token. Such messages include but are not
limited to: limited to:
o NACK messages [RFC4585] o NACK messages [RFC4585]
o RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp] o RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
Additionally, some RTCP messages might directly or indirectly control Additionally, some RTCP messages might directly or indirectly control
an existing unicast session associated with a multicast session. an existing unicast session associated with a multicast session.
Unless another authentication method as described in their respective Unless another authentication method as described in their respective
specifications is used, such RTCP messages might also need to be specifications is used, implementations MUST support authenticating
authenticated by using a Token. Examples are: such RTCP messages by using a Token.
Examples are:
o BYE messages [RFC3550] o BYE messages [RFC3550]
o RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp] o RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
o CCM messages [RFC5104] o CCM messages [RFC5104]
Note that even if a packet type is listed to require Token-based Note that even if a packet type is listed to require Token-based
authentication, it does not need to be authenticated when it does not authentication, it does not need to be authenticated when it does not
control the unicast session. For example, if BYE (203) is listed in control the unicast session. For example, if BYE (203) is listed in
skipping to change at page 21, line 19 skipping to change at page 21, line 19
During Token construction, the expiration time has to be chosen During Token construction, the expiration time has to be chosen
carefully based on the intended service duration. Tokens that are carefully based on the intended service duration. Tokens that are
valid for an unnecessarily long period of time (e.g., several hours) valid for an unnecessarily long period of time (e.g., several hours)
might impose security risks. Depending on the application and use might impose security risks. Depending on the application and use
cases, a reasonable value needs to be chosen by the server. Note cases, a reasonable value needs to be chosen by the server. Note
that using shorter lifetimes requires the clients to acquire Tokens that using shorter lifetimes requires the clients to acquire Tokens
more frequently. However, since a client can acquire a new Token more frequently. However, since a client can acquire a new Token
well before it will need to use it, the client will not necessarily well before it will need to use it, the client will not necessarily
be penalized for the acquisition delay. be penalized for the acquisition delay.
Finally, be aware that NTP timestamps will wrap around in year 2036 Finally, be aware that NTP timestamps will wrap around in year 2036.
and implementations might need to handle this eventually. Refer to Refer to Section 6 of [RFC5905] for further details.
Section 6 of [RFC5905] for further details.
6. Validating Tokens 6. Validating Tokens
Upon receipt of an RTCP feedback message along with the Token Upon receipt of an RTCP feedback message along with the Token
Verification Request message that contains a Token, nonce and Verification Request message that contains a Token, nonce and
absolute expiration time, the server MUST validate the Token. absolute expiration time, the server MUST validate the Token.
The server first applies its own procedure for constructing the The server first applies its own procedure for constructing the
Tokens by using client's IP address from the received Token Tokens by using client's IP address from the received Token
Verification Request message, and the nonce and absolute expiration Verification Request message, and the nonce and absolute expiration
skipping to change at page 23, line 39 skipping to change at page 23, line 39
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-attr = "a=portmapping-req" [":" port [SP nettype SP portmapping-req-attr = "a=portmapping-req" [":" port [SP nettype SP
addrtype SP 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]. defined as specified in Section 9 of [RFC4566].
The 'portmapping-req' attribute SHALL be used as a media-level The 'portmapping-req' attribute SHALL only be used as a media-level
attribute. attribute.
In the optional address value, only unicast addresses SHOULD be used In the optional address value, only unicast addresses SHOULD be used
unless one wants to use a multicast address after evaluating the unless one wants to use a multicast address after evaluating the
additional security risks such as non-legit servers generating fake additional security risks such as non-legit servers generating fake
Tokens. If the address is not specified, the (source) address in the Tokens. If the address is not specified, the (source) address in the
"c" line applicable to the media description SHALL be used. "c" line applicable to the media description SHALL be used.
7.1.2. Offer/Answer Model Considerations 7.1.2. Offer/Answer Model Considerations
skipping to change at page 30, line 33 skipping to change at page 30, line 33
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: 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 RTCP Control Packet Types 10.2. Registration of RTCP Control Packet Types
In accordance with Section 15 of [RFC3550], this specification adds In accordance with Section 15 of [RFC3550], this specification adds
the following value to the RTCP Control Packet types sub-registry of the following value to the RTCP Control Packet types sub-registry in
the Real-Time Transport Protocol (RTP) Parameters registry: the Real-Time Transport Protocol (RTP) Parameters registry:
Value Abbrev. Name Reference Value Abbrev. Name Reference
-------- --------- --------------------------------------- --------- -------- --------- --------------------------------------- ---------
TBD TOKEN Port Mapping [RFCXXXX] TBD TOKEN Port Mapping [RFCXXXX]
Note to the IANA: Please assign the next available value, which is Note to the IANA: Please assign the next available value, which is
currently 210. currently 210.
10.3. SMT Values for TOKEN Packet Type Registry 10.3. SMT Values for TOKEN Packet Type Registry
skipping to change at page 34, line 36 skipping to change at page 34, line 36
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[I-D.ietf-avt-app-rtp-keepalive] [I-D.ietf-avt-app-rtp-keepalive]
Marjou, X. and A. Sollaud, "Application Mechanism for Marjou, X. and A. Sollaud, "Application Mechanism for
keeping alive the Network Address Translator (NAT) keeping alive the Network Address Translator (NAT)
mappings associated to RTP flows.", mappings associated to RTP/RTCP flows.",
draft-ietf-avt-app-rtp-keepalive-09 (work in progress), draft-ietf-avt-app-rtp-keepalive-10 (work in progress),
September 2010. March 2011.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
 End of changes. 12 change blocks. 
35 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/