draft-ietf-avt-ports-for-ucast-mcast-rtp-03.txt   draft-ietf-avt-ports-for-ucast-mcast-rtp-04.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: May 22, 2011 T. VanCaenegem Expires: May 27, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
November 18, 2010 November 23, 2010
Token-Based Port Mapping Between Unicast and Multicast RTP Sessions Port Mapping Between Unicast and Multicast RTP Sessions
draft-ietf-avt-ports-for-ucast-mcast-rtp-03 draft-ietf-avt-ports-for-ucast-mcast-rtp-04
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 in RTP applications using both unicast and multicast services
(almost) without the need for retrieving pre-authorization. (almost) without the need for retrieving pre-authorization.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 May 22, 2011. This Internet-Draft will expire on May 27, 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 17 skipping to change at page 2, line 17
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
4. The portmapping-req Attribute . . . . . . . . . . . . . . . . 11 4. The portmapping-req Attribute . . . . . . . . . . . . . . . . 11
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 13 5.1. Port Mapping Request . . . . . . . . . . . . . . . . . . . 13
5.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13 5.2. Port Mapping Response . . . . . . . . . . . . . . . . . . 13
5.3. Token Verification . . . . . . . . . . . . . . . . . . . . 14 5.3. Token Verification Request . . . . . . . . . . . . . . . . 15
6. Procedures for Token Construction . . . . . . . . . . . . . . 15 5.4. Token Verification Failure . . . . . . . . . . . . . . . . 15
7. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 16 6. Procedures for Token Construction . . . . . . . . . . . . . . 17
8. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Validating Tokens . . . . . . . . . . . . . . . . . . . . . . 18
9. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 19 8. SDP Example . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Address Pooling NATs . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11.2. Registration of FMT Values . . . . . . . . . . . . . . . . 21 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 23
11.3. SFMT Values for Port Mapping Messages Registry . . . . . . 21 11.2. Registration of FMT Values . . . . . . . . . . . . . . . . 23
11.4. RAMS Response Code Space Registry . . . . . . . . . . . . 22 11.3. SFMT Values for Port Mapping Messages Registry . . . . . . 23
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11.4. RAMS Response Code Space Registry . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 13.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
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 6, line 18 skipping to change at page 6, line 18
and retrieval, and (ii) unicast session establishment. These are and retrieval, and (ii) unicast session establishment. These are
described below. described below.
3.1. Token Request and Retrieval 3.1. Token Request and Retrieval
This first step is required to be completed only once. Once a Token This first step is required to be completed only once. Once a Token
is retrieved from a particular server, it can be used for all the is retrieved from a particular server, it can be used for all the
unicast sessions the client will be running with this particular unicast sessions the client will be running with this particular
server. By default, Tokens are server specific. However, the client server. By default, Tokens are server specific. However, the client
can use the same Token to communicate with different servers if these can use the same Token to communicate with different servers if these
servers are provided with the same key used to generate the Token. servers are provided with the same secret key used to generate the
The Token becomes invalid if client's public IP address changes or Token and are at least loosely clock-synchronized. The Token becomes
when the server expires the Token. In these cases, the client has to invalid if client's public IP address changes or when the server
request a new Token. expires the Token. In these cases, the client has to request a new
Token.
The Token is essentially an opaque encapsulation that conveys The Token is essentially an opaque encapsulation that conveys
client's IP address information (as seen by the server) using a client's IP address information (as seen by the server) using a
reversible transform only known to the server. When a request is reversible transform only known to the server. When a request is
received, the server creates a Token for this particular client, and received, the server creates a Token for this particular client, and
sends it back to the client. Later, when the client wants to sends it back to the client. Later, when the client wants to
establish a unicast session, the Token will be validated by the establish a unicast session, the Token will be validated by the
server, making sure that the IP address information matches. This is server, making sure that the IP address information matches. This is
effective against DoS attacks, e.g., an attacker cannot simply spoof effective against DoS attacks, e.g., an attacker cannot simply spoof
another client's IP address and start a unicast transmission towards another client's IP address and start a unicast transmission towards
skipping to change at page 9, line 47 skipping to change at page 9, line 47
B. The server generates an opaque encapsulation (i.e., the B. The server generates an opaque encapsulation (i.e., the
Token) that conveys client's IP address information using a Token) that conveys client's IP address information using a
reversible transform only known to the server. For details, reversible transform only known to the server. For details,
see Section 6. see Section 6.
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 provides the Token to the server using a new RTCP 4. The client provides the Token to the server using a new RTCP
message, called Token Verification, whenever the client sends an message, called Token Verification Request, whenever the client
RTCP feedback message for triggering or controlling a unicast sends an RTCP feedback message for triggering or controlling a
session. Note that the unicast session is only established after unicast session. Note that the unicast session is only
the server has received a feedback message (along with a valid established after the server has received a feedback message
Token) from the client for which it needs to react by sending (along with a valid Token) from the client for which it needs to
unicast data. Until a unicast session is established, neither react by sending unicast data. Until a unicast session is
the server nor the client needs to send RTCP reports for the established, neither the server nor the client needs to send RTCP
unicast session. reports for the unicast session.
5. Normal flows ensue as shown in Figure 2. Note that in the 5. Normal flows ensue as shown in Figure 2. Note that in the
unicast session the RTP and RTCP packets MUST be multiplexed on unicast session the RTP and RTCP packets MUST be multiplexed on
the (same) port c1. If the client uses the same port for both c0 the (same) port c1. If the client uses the same port for both c0
and c1, the RTCP reports sent for the multicast session keep the and c1, the RTCP reports sent for the multicast session keep the
P3->c1(=c0) binding alive. If the client uses different ports P3->c1(=c0) binding alive. If the client uses different ports
for c0 and c1, the client needs to periodically send an explicit for c0 and c1, the client needs to periodically send an explicit
keep-alive message [I-D.ietf-avt-app-rtp-keepalive] to keep the keep-alive message [I-D.ietf-avt-app-rtp-keepalive] to keep the
P3->c1 binding alive during the lifetime of the unicast session P3->c1 binding alive during the lifetime of the unicast session
if the unicast session's lifetime is likely to exceed the NAT's if the unicast session's lifetime is likely to exceed the NAT's
skipping to change at page 12, line 9 skipping to change at page 12, line 9
portmapping-req-attribute = "a=portmapping-req:" port CRLF portmapping-req-attribute = "a=portmapping-req:" port CRLF
Here, 'port' is defined as specified in Section 9 of [RFC4566]. The Here, 'port' is defined as specified in Section 9 of [RFC4566]. The
'portmapping-req' attribute is used as a session-level or media-level 'portmapping-req' attribute is used as a session-level or media-level
attribute. attribute.
5. Message Formats 5. Message Formats
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between a server and a client for the messages that are exchanged between a server and a client for the
purpose of Token-based port mapping. Three RTCP messages are purpose of Token-based port mapping. Four RTCP messages are defined:
defined:
1. Port Mapping Request 1. Port Mapping Request
2. Port Mapping Response 2. Port Mapping Response
3. Token Verification 3. Token Verification Request
4. Token Verification Failure
These are all payload-independent RTCP feedback messages with a These are all payload-independent RTCP feedback messages with a
common format defined in Section 6.1 of [RFC4585], also sketched in common format defined in Section 6.1 of [RFC4585], also sketched in
Figure 3. Figure 3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length | |V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 28 skipping to change at page 13, line 28
| SFMT=1 | Reserved | | SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random | | Random |
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The FCI field of Port Mapping Request message Figure 4: The FCI field of Port Mapping Request message
o Random Nonce (64 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 MUST be taken into account by the server [RFC4086]. This nonce is taken into account by the server when
when generating a Token for the client to enable better security generating a Token for the client to enable better security for
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. duplicated messages.
5.2. Port Mapping Response 5.2. Port Mapping Response
The Port Mapping Response message is identified by SFMT=2. This The Port Mapping Response message is identified by SFMT=2. This
message is sent by the server and delivers the Token to the client. message is sent by the server and delivers the Token to the client.
In the Port Mapping Response message, the packet sender SSRC and In the Port Mapping Response message, the packet sender SSRC and
media sender SSRC fields are both set to the client's SSRC since the media sender SSRC fields are both set to the client's SSRC since the
Port Mapping Response message is not necessarily linked to any Port Mapping Response message is not necessarily linked to any
specific media source. The FCI field has the structure depicted in specific media source. The FCI field has the structure depicted in
Figure 5. 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 | Reserved | | SFMT=2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token : : Token :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiry Time | | Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Absolute |
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relative Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FCI field syntax for the Port Mapping Response message Figure 5: FCI field syntax for the Port Mapping Response message
o Token (128 bits): Mandatory element that contains the Token o Token (128 bits): Mandatory element that contains the Token
generated by the server. generated by the server.
o Expiry Time (32 bits): Mandatory element that contains the expiry o Associated Nonce (64 bits): Mandatory field that contains the
time of the Token. The expiry time is expressed in seconds from nonce received in the Port Mapping Request message and used in
the time the Token was generated. An expiry time of zero Token construction.
indicates that the accompanying Token is not valid.
5.3. Token Verification o Absolute Expiration Time (64 bits): Mandatory element that
contains the absolute expiration time of the Token. The absolute
expiration time is expressed as a Network Time Protocol (NTP)
timestamp value in seconds since year 1900 [RFC5905]. The client
does not need to use this element directly, thus, does not need to
synchronize its clock with the server. However, the client needs
to send this element back to the server along with the associated
nonce in the Token Verification Request message, thus, needs to
keep it associated with the Token.
The Token Verification message is identified by SFMT=3. This message o Relative Expiration Time (32 bits): Mandatory element that
contains the Token and MUST accompany any other RTCP feedback message contains the relative expiration time of the Token. The relative
sent by the client to trigger or control a unicast session. Examples expiration time is expressed in seconds from the time the Token
include the RAMS-R and RAMS-T messages was generated. A relative expiration time of zero indicates that
the accompanying Token is not valid.
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 expiration time.
5.3. Token Verification Request
The Token Verification Request message is identified by SFMT=3. This
message contains the Token and MUST accompany any other RTCP feedback
message sent by the client to trigger or control a unicast session.
Examples include the RAMS-R and RAMS-T messages
[I-D.ietf-avt-rapid-acquisition-for-rtp] as well as the NACK messages [I-D.ietf-avt-rapid-acquisition-for-rtp] as well as the NACK messages
[RFC4585]. In the Token Verification message, the client MUST set [RFC4585]. In the Token Verification Request message, the client
both the packet sender SSRC and media source SSRC fields to its own MUST set both the packet sender SSRC and media source SSRC fields to
SSRC since the media source SSRC may not be known. The client MUST its own SSRC since the media source SSRC may not be known. The
NOT send a Token Verification message with a Token that has expired. client MUST NOT send a Token Verification Request message with a
The FCI field has the structure depicted in Figure 6. Token that has 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 | Reserved | | SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Token : : Token :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated |
| Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated Absolute |
| Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the Token Verification message Figure 6: FCI field syntax for the Token Verification message
o Token (128 bits): Mandatory element that contains the Token o Token (128 bits): Mandatory element that contains the Token
previously acquired by the client. previously acquired by the client.
6. Procedures for Token Construction o Associated Nonce (64 bits): Mandatory field that contains the
nonce associated with the Token above.
Editor's notes: o Associated Absolute Expiration Time (64 bits): Mandatory element
that contains the absolute expiration time associated with the
Token above.
The Token SHOULD be calculated by the server by taking into account: 5.4. Token Verification Failure
o Client's IP address as seen by the server The Token Verification Failure message is identified by SFMT=4. This
message is sent by the server and notifies the client that the Token
was invalid. In the Token Verification Failure message, the packet
sender SSRC and media sender SSRC fields are both set to the client's
SSRC. The FCI field has the structure depicted in Figure 6.
o The nonce generated by the client and inserted in the Port Mapping 0 1 2 3
Request message 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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o A timestamp to protect against replay attacks Figure 7: FCI field syntax for the Token Failure message
o HMAC [RFC2104] of the above information (where only the server 6. Procedures for Token Construction
knows the HMAC secret)
The server conveys the expiration time in the clear to the client in The Token is calculated by the server by performing HMAC-SHA1
the Port Mapping Response message. Thus, the client can request a [RFC2104] on the concatenated values of:
new Token before the current one expires.
Details are TBC. o Client's IP address as seen by the server (32/128 bits for IPv4/
IPv6 addresses)
o The nonce generated and inserted in the Port Mapping Request
message by the client (64 bits)
o The absolute expiration time chosen by the server indicated as an
NTP timestamp value in seconds since year 1900 [RFC5905] (64 bits,
to protect against replay attacks)
After performing the HMAC-SHA1, the output is truncated to 128 bits,
which is then converted to ASCII using Base64 encoding [RFC4648]. In
this process, only the server knows the HMAC secret key. However,
the HMAC secret key can be shared by multiple servers to provide
portability for the Tokens.
7. Validating Tokens 7. 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 message that contains a Token, the server MUST validate Verification Request message that contains a Token, nonce and
the Token. The server considers a Token valid if the source IP absolute expiration time, the server MUST validate the Token.
address of the RTCP feedback message matches the IP address in the
Token and the Token has not expired yet.
The IP address is encoded into the Token by the server, using an The server first applies the procedure given in Section 6 by using
algorithm known only to the server. This, combined with the client's IP address from the received Token Verification Request
expiration time provides protection against DoS attacks so that a message, and the nonce and absolute expiration time values reported
client using a certain IP address cannot cause one or more RTP in the received Token Verification Request message. The server then
packets to be sent to another client with a different IP address. compares the resulting output with the Token sent by the client in
the Token Verification Request message. If they match and the
absolute expiration time has not passed yet, the server declares that
the Token is valid.
When the server detects that the Token is invalid, it SHOULD NOT Note that if the client's IP address changes, the Token will not
silently discard client's message since this adds an undesired delay. validate. Similarly, if the client inserts an incorrect nonce or
Instead, it is RECOMMENDED that applications define an application- absolute expiration time value in the Token Verification Request
specific error response. In applications that have not defined an message, validation will fail.
error response, the server MUST reply back to the client with a Port
Mapping Response message (that goes from port P3 on the server to
port c1 on the client) where the Token field carries the invalid
Token sent by the client and the Expiry Time field is set to zero
(indicating that the Token is invalid).
For applications using [I-D.ietf-avt-rapid-acquisition-for-rtp], this It is RECOMMENDED that applications define an application-specific
draft defines a new 4xx-level response code in the RAMS Response Code error response to be sent by the server when the server detects that
Space Registry. the Token is invalid, rather than silently discarding client's
message (since this adds an undesired delay). For applications using
[I-D.ietf-avt-rapid-acquisition-for-rtp], this draft defines a new
4xx-level response code in the RAMS Response Code Space Registry.
In applications that have not defined an error response, the server
MUST reply back to the client with a Token Verification Failure
message (that goes from port P3 on the server to port c1 on the
client).
8. SDP Example 8. SDP Example
The declarative SDP describing the scenario given in Figure 2 is The declarative SDP describing the scenario given in Figure 2 is
written as: written as:
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 nack.example.com o=ali 1122334455 1122334466 IN IP4 nack.example.com
s=Local Retransmissions s=Local Retransmissions
t=0 0 t=0 0
skipping to change at page 17, line 36 skipping to change at page 19, line 36
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 7: 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 (DS) to the multicast
destination address of 233.252.0.2 (G) and port 41000 (P1). The 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 associated RTCP packets are multicast in the same group to port 41500
(P2). (P2).
skipping to change at page 19, line 7 skipping to change at page 21, line 7
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).
9. Address Pooling NATs 9. Address Pooling NATs
Large-scale NAT (LSN) devices have a pool of public IPv4 addresses Large-scale NAT devices have a pool of public IPv4 addresses and map
and map internal hosts to one of those public IPv4 addresses. As internal hosts to one of those public IPv4 addresses. As long as an
long as an internal host maintains an active mapping in the NAT, the internal host maintains an active mapping in the NAT, the same IPv4
same IPv4 address is assigned to new connections. However, once all address is assigned to new connections. However, once all of the
of the host's mappings have been deleted (e.g., because of timeout), host's mappings have been deleted (e.g., because of timeout), it is
it is possible that a new connection from that same host will be possible that a new connection from that same host will be assigned a
assigned a different IPv4 address from the pool. When that occurs, different IPv4 address from the pool. When that occurs, the Token
the Token will be considered invalid by the server, causing an will be considered invalid by the server, causing an additional round
additional round trip for the client to acquire a fresh Token. trip for the client to acquire a fresh Token.
Any traffic from the host which traverses the NAT will prevent this Any traffic from the host which traverses the NAT will prevent this
problem. As the host is sending RTCP receiver reports at least every 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 5 seconds (Section 6.2 of [RFC3550]) for the multicast session it is
receiving, those RTCP messages will be sufficient to prevent this receiving, those RTCP messages will be sufficient to prevent this
problem. problem.
10. Security Considerations 10. Security Considerations
The Token, which is generated based on a client's IP address and The Token, which is generated based on a client's IP address and
expiration date, provides protection against denial-of-service (DoS) expiration date, provides protection against denial-of-service (DoS)
attacks. An attacker using a certain IP address cannot cause one or 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 more RTP packets to be sent to a victim client who has a different IP
address. However, if the attacker acquires a valid Token for a address. However, if the attacker acquires a valid Token for a
victim and can spoof the victim's source address, this approach victim and can spoof the victim's source address, this approach
becomes vulnerable to replay attacks. becomes vulnerable to replay attacks. This is especially easy if the
attacker and victim are behind a large-scale NAT and share the same
IP address.
Multicast is deployed on managed networks - not the Internet. These Multicast is deployed on managed networks - not the Internet. These
managed networks will choose to enable network ingress filtering managed networks will choose to enable network ingress filtering
[RFC2827] or not. If ingress filtering is enabled on a network, an [RFC2827] or not. If ingress filtering is enabled on a network, an
attacker attacker cannot spoof a victim's IP address to use a Token attacker attacker cannot spoof a victim's IP address to use a Token
to initiate an attack against a victim. However, if ingress to initiate an attack against a victim. However, if ingress
filtering is not enabled on a network, an attacker could obtain a filtering is not enabled on a network, an attacker could obtain a
Token and spoof the victim's address, causing traffic to flood the Token and spoof the victim's address, causing traffic to flood the
victim. On such a network, the server can reduce the time period for victim. On such a network, the server can reduce the time period for
such an attack by expiring a Token in a short period of time. In the such an attack by expiring a Token in a short period of time. In the
extreme case, the server can expire the Token immediately after its extreme case, the server can expire the Token in such a short period
first use. An expired Token forces a round trip from the client to of time, such that the client will have to acquire a new Token
the server. immediately before using it in a Token Verification Request message.
11. IANA Considerations 11. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
skipping to change at page 22, line 11 skipping to change at page 24, line 11
The length of the SFMT field in the Port Mapping messages is a single The length of the SFMT field in the Port Mapping messages is a single
octet, allowing 256 values. The registry is initialized with the octet, allowing 256 values. 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 [RFCXXXX] 3 Token Verification Request [RFCXXXX]
4-254 Assignable - Specification Required 4 Token Verification Failure [RFCXXXX]
5-254 Assignable - Specification Required
255 Reserved [RFCXXXX] 255 Reserved [RFCXXXX]
The SFMT values 0 and 255 are reserved for future use. The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value needs to contain the Any registration for an unassigned SFMT 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, address, and email.
skipping to change at page 24, line 34 skipping to change at page 26, line 34
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
13.2. Informative References 13.2. Informative References
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
skipping to change at page 25, line 16 skipping to change at page 27, line 27
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 flows.",
draft-ietf-avt-app-rtp-keepalive-09 (work in progress), draft-ietf-avt-app-rtp-keepalive-09 (work in progress),
September 2010. September 2010.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[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.
Authors' Addresses Authors' Addresses
 End of changes. 37 change blocks. 
110 lines changed or deleted 181 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/