draft-thornburgh-adobe-rtmfp-08.txt   draft-thornburgh-adobe-rtmfp-09.txt 
Network Working Group M. Thornburgh Network Working Group M. Thornburgh
Internet-Draft Adobe Internet-Draft Adobe
Intended status: Informational June 25, 2013 Intended status: Informational June 28, 2013
Expires: December 27, 2013 Expires: December 30, 2013
Adobe's Secure Real-Time Media Flow Protocol Adobe's Secure Real-Time Media Flow Protocol
draft-thornburgh-adobe-rtmfp-08 draft-thornburgh-adobe-rtmfp-09
Abstract Abstract
This memo describes Adobe's Secure Real-Time Media Flow Protocol This memo describes Adobe's Secure Real-Time Media Flow Protocol
(RTMFP), an endpoint-to-endpoint communication protocol designed to (RTMFP), an endpoint-to-endpoint communication protocol designed to
securely transport parallel flows of real-time video, audio, and data securely transport parallel flows of real-time video, audio, and data
messages, as well as bulk data, over IP networks. RTMFP has features messages, as well as bulk data, over IP networks. RTMFP has features
making it effective for peer-to-peer (P2P) as well as client-server making it effective for peer-to-peer (P2P) as well as client-server
communications, even when Network Address Translators (NATs) are communications, even when Network Address Translators (NATs) are
used. used.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 December 27, 2013. This Internet-Draft will expire on December 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Design Highlights of RTMFP . . . . . . . . . . . . . . . 5 1.1. Design Highlights of RTMFP . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Common Elements . . . . . . . . . . . . . . . . . . . . . 7 2.1. Common Elements . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Elementary Types and Constructs . . . . . . . . . . . 8 2.1.1. Elementary Types and Constructs . . . . . . . . . . . 8
2.1.2. Variable Length Unsigned Integer (VLU) . . . . . . . 9 2.1.2. Variable Length Unsigned Integer (VLU) . . . . . . . 9
2.1.3. Option . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.3. Option . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4. Option List . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Option List . . . . . . . . . . . . . . . . . . . . . 11
2.1.5. Internet Socket Address (Address) . . . . . . . . . . 11 2.1.5. Internet Socket Address (Address) . . . . . . . . . . 11
2.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Encapsulation . . . . . . . . . . . . . . . . . . . . 12 2.2.1. Encapsulation . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Multiplex . . . . . . . . . . . . . . . . . . . . . . 13 2.2.2. Multiplex . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3. Encryption . . . . . . . . . . . . . . . . . . . . . 14 2.2.3. Encryption . . . . . . . . . . . . . . . . . . . . . 14
2.2.4. Packet . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.4. Packet . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1. Packet Fragment Chunk . . . . . . . . . . . . . . . . 19 2.3.1. Packet Fragment Chunk . . . . . . . . . . . . . . . . 19
2.3.2. Initiator Hello Chunk (IHello) . . . . . . . . . . . 20 2.3.2. Initiator Hello Chunk (IHello) . . . . . . . . . . . 20
2.3.3. Forwarded Initiator Hello Chunk (FIHello) . . . . . . 20 2.3.3. Forwarded Initiator Hello Chunk (FIHello) . . . . . . 20
skipping to change at page 5, line 8 skipping to change at page 5, line 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 102
7.2. Informative References . . . . . . . . . . . . . . . . . 102 7.2. Informative References . . . . . . . . . . . . . . . . . 102
Appendix A. Example Congestion Control Algorithm . . . . . . . . 103 Appendix A. Example Congestion Control Algorithm . . . . . . . . 103
A.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 103 A.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 103
A.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 104 A.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 104
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 107
1. Introduction 1. Introduction
Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for
use as an endpoint-to-endpoint data transport service in IP networks. use as a general purpose endpoint-to-endpoint data transport service
It has features that make it well suited to the transport of real- in IP networks. It has features that make it well suited to the
time media (such as low-delay video, audio, and data) as well as bulk transport of real-time media (such as low-delay video, audio, and
data, and for client-server as well as peer-to-peer (P2P) data) as well as bulk data, and for client-server as well as peer-to-
communication. These features include independent parallel message peer (P2P) communication. These features include independent
flows which may have different delivery priorities, variable message parallel message flows which may have different delivery priorities,
reliability (from TCP-like full reliability to UDP-like best effort), variable message reliability (from TCP-like full reliability to UDP-
multi-point congestion control, and built-in security. Session like best effort), multi-point congestion control, and built-in
multiplexing and facilities to support UDP hole-punching simplify security. Session multiplexing and facilities to support UDP hole-
Network Address Translator (NAT) traversal in peer-to-peer systems. punching simplify Network Address Translator (NAT) traversal in peer-
to-peer systems.
RTMFP is implemented in Flash Player, Adobe Integrated Runtime (AIR), RTMFP is implemented in Flash Player, Adobe Integrated Runtime (AIR),
and Adobe Media Server (AMS, formerly Flash Media Server or FMS), all and Adobe Media Server (AMS, formerly Flash Media Server or FMS), all
from Adobe Systems Incorporated, and is used as the foundation from Adobe Systems Incorporated, and is used as the foundation
transport protocol for real-time video, audio, and data transport protocol for real-time video, audio, and data
communication, both client-server and P2P, in those products. At the communication, both client-server and P2P, in those products. At the
time of writing, the Adobe Flash Player runtime is installed on more time of writing, the Adobe Flash Player runtime is installed on more
than one billion end-user desktop computers. than one billion end-user desktop computers.
RTMFP was developed by Adobe Systems Incorporated, and is not the RTMFP was developed by Adobe Systems Incorporated, and is not the
product of an IETF activity. product of an IETF activity.
This memo describes the syntax and operation of the Secure Real-Time This memo describes the syntax and operation of the Secure Real-Time
Media Flow Protocol. Media Flow Protocol.
This memo describes a general security framework that can be used to
establish a confidential and authenticated session between endpoints.
An application-specific Cryptography Profile, not defined herein,
would detail the specific cryptographic algorithms, data formats, and
semantics to be used within this framework. Interoperation between
applications of RTMFP requires common or compatible Cryptography
Profiles.
1.1. Design Highlights of RTMFP 1.1. Design Highlights of RTMFP
Between any pair of communicating endpoints is a single, Between any pair of communicating endpoints is a single,
bidirectional, secured, congestion controlled session. bidirectional, secured, congestion controlled session.
Unidirectional flows convey messages from one end to the other within Unidirectional flows convey messages from one end to the other within
the session. An endpoint can have concurrent sessions with multiple the session. An endpoint can have concurrent sessions with multiple
other far endpoints. other far endpoints.
Design highlights of RTMFP include: Design highlights of RTMFP include:
o The security framework is an in-band part of the basic protocol o The security framework is an inherent part of the basic protocol.
and is always on. The application designer chooses the The application designer chooses the cryptographic formats and
cryptographic formats and algorithms to suit the needs of the algorithms to suit the needs of the application, and may update
application, and may update them as the state of the security arts them as the state of the security arts progresses.
progresses.
o Cryptographic Endpoint Discriminators can resist port scanning. o Cryptographic Endpoint Discriminators can resist port scanning.
o All header, control, and framing information, except for network o All header, control, and framing information, except for network
addressing information and a session identifier, is encrypted. addressing information and a session identifier, is encrypted
according to the Cryptography Profile.
o There is a single session and associated congestion control state o There is a single session and associated congestion control state
between a pair of endpoints. between a pair of endpoints.
o Each session may have zero or more unidirectional message-oriented o Each session may have zero or more unidirectional message-oriented
flows in each direction. All of a session's sending flows share flows in each direction. All of a session's sending flows share
the session's congestion control state. the session's congestion control state.
o Return Flow Association (Section 2.3.11.1.2) generalizes o Return Flow Association (Section 2.3.11.1.2) generalizes
bidirectional communication to arbitrarily complex trees of flows. bidirectional communication to arbitrarily complex trees of flows.
skipping to change at page 14, line 8 skipping to change at page 14, line 8
session and implies the Default Session Key. session and implies the Default Session Key.
Note: If the encrypted packet is less than 8 bytes long, then for the Note: If the encrypted packet is less than 8 bytes long, then for the
scrambling operation, perform the exclusive-or as though the scrambling operation, perform the exclusive-or as though the
encrypted packet were end-padded with enough 0-bytes to bring its encrypted packet were end-padded with enough 0-bytes to bring its
length to 8. length to 8.
2.2.3. Encryption 2.2.3. Encryption
RTMFP packets are encrypted according to a Cryptography Profile. RTMFP packets are encrypted according to a Cryptography Profile.
This specification doesn't mandate a particular choice of This specification doesn't define a Cryptography Profile or mandate a
cryptography. The application defines the cryptographic syntax and particular choice of cryptography. The application defines the
algorithms. cryptographic syntax and algorithms.
Packet encryption is RECOMMENDED to be a block cipher operating in Packet encryption is RECOMMENDED to be a block cipher operating in
Cipher Block Chaining [CBC] or similar mode. Encrypted packets MUST Cipher Block Chaining [CBC] or similar mode. Encrypted packets MUST
be decipherable without inter-packet dependency, since packets may be be decipherable without inter-packet dependency, since packets may be
lost, duplicated, or reordered in the network. lost, duplicated, or reordered in the network.
The packet encryption layer is responsible for data integrity and The packet encryption layer is responsible for data integrity and
authenticity of packets, for example by means of a checksum or authenticity of packets, for example by means of a checksum or
cryptographic message authentication code. To mitigate replay cryptographic message authentication code. To mitigate replay
attacks, data integrity SHOULD comprise duplicate packet detection, attacks, data integrity SHOULD comprise duplicate packet detection,
 End of changes. 10 change blocks. 
25 lines changed or deleted 34 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/