RFC 7016
Adobe's Secure Real-Time Media Flow Protocol
Pages: 113
Informational
Informational
Part 1 of 4 – Pages 1 to 13
Internet Engineering Task Force (IETF) M. Thornburgh Request for Comments: 7016 Adobe Category: Informational November 2013 ISSN: 2070-1721 Adobe's Secure Real-Time Media Flow ProtocolAbstract
This memo describes Adobe's Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client- server communications, even when Network Address Translators (NATs) are used. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7016. IESG Note This document represents technology developed outside the processes of the IETF and the IETF community has determined that it is useful to publish it as an RFC in its current form. It is a product of the IETF only in that it has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG), but the content of the document does not represent a consensus of the IETF.
Copyright Notice Copyright (c) 2013 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 described in the Simplified BSD License. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction ....................................................5 1.1. Design Highlights of RTMFP .................................6 1.2. Terminology ................................................7 2. Syntax ..........................................................8 2.1. Common Elements ............................................8 2.1.1. Elementary Types and Constructs .....................8 2.1.2. Variable Length Unsigned Integer (VLU) .............10 2.1.3. Option .............................................10 2.1.4. Option List ........................................11 2.1.5. Internet Socket Address (Address) ..................12 2.2. Network Layer .............................................13 2.2.1. Encapsulation ......................................13 2.2.2. Multiplex ..........................................13 2.2.3. Encryption .........................................14 2.2.4. Packet .............................................15 2.3. Chunks ....................................................18 2.3.1. Packet Fragment Chunk ..............................20 2.3.2. Initiator Hello Chunk (IHello) .....................21 2.3.3. Forwarded Initiator Hello Chunk (FIHello) ..........22 2.3.4. Responder Hello Chunk (RHello) .....................23 2.3.5. Responder Redirect Chunk (Redirect) ................24 2.3.6. RHello Cookie Change Chunk .........................26 2.3.7. Initiator Initial Keying Chunk (IIKeying) ..........27 2.3.8. Responder Initial Keying Chunk (RIKeying) ..........29 2.3.9. Ping Chunk .........................................31 2.3.10. Ping Reply Chunk ..................................32
2.3.11. User Data Chunk ...................................33
2.3.11.1. Options for User Data ....................35
2.3.11.1.1. User's Per-Flow Metadata ......35
2.3.11.1.2. Return Flow Association .......36
2.3.12. Next User Data Chunk ..............................37
2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) ....39
2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) .....41
2.3.15. Buffer Probe Chunk ................................43
2.3.16. Flow Exception Report Chunk .......................43
2.3.17. Session Close Request Chunk (Close) ...............44
2.3.18. Session Close Acknowledgement Chunk (Close Ack) ...44
3. Operation ......................................................45
3.1. Overview ..................................................45
3.2. Endpoint Identity .........................................46
3.3. Packet Multiplex ..........................................48
3.4. Packet Fragmentation ......................................48
3.5. Sessions ..................................................50
3.5.1. Startup ............................................53
3.5.1.1. Normal Handshake ..........................53
3.5.1.1.1. Initiator ......................54
3.5.1.1.2. Responder ......................55
3.5.1.2. Cookie Change .............................57
3.5.1.3. Glare .....................................59
3.5.1.4. Redirector ................................60
3.5.1.5. Forwarder .................................61
3.5.1.6. Redirector and Forwarder with NAT .........63
3.5.1.7. Load Distribution and Fault Tolerance .....66
3.5.2. Congestion Control .................................67
3.5.2.1. Time Critical Reverse Notification ........68
3.5.2.2. Retransmission Timeout ....................68
3.5.2.3. Burst Avoidance ...........................71
3.5.3. Address Mobility ...................................71
3.5.4. Ping ...............................................72
3.5.4.1. Keepalive .................................72
3.5.4.2. Address Mobility ..........................73
3.5.4.3. Path MTU Discovery ........................74
3.5.5. Close ..............................................74
3.6. Flows .....................................................75
3.6.1. Overview ...........................................75
3.6.1.1. Identity ..................................75
3.6.1.2. Messages and Sequencing ...................76
3.6.1.3. Lifetime ..................................77
3.6.2. Sender .............................................78
3.6.2.1. Startup ...................................80
3.6.2.2. Queuing Data ..............................80
3.6.2.3. Sending Data ..............................81
3.6.2.3.1. Startup Options ................83
3.6.2.3.2. Send Next Data .................83
3.6.2.4. Processing Acknowledgements ...............83
3.6.2.5. Negative Acknowledgement and Loss .........84
3.6.2.6. Timeout ...................................85
3.6.2.7. Abandoning Data ...........................86
3.6.2.7.1. Forward Sequence Number
Update .........................86
3.6.2.8. Examples ..................................87
3.6.2.9. Flow Control ..............................89
3.6.2.9.1. Buffer Probe ...................89
3.6.2.10. Exception ................................89
3.6.2.11. Close ....................................90
3.6.3. Receiver ...........................................90
3.6.3.1. Startup ...................................93
3.6.3.2. Receiving Data ............................94
3.6.3.3. Buffering and Delivering Data .............95
3.6.3.4. Acknowledging Data ........................97
3.6.3.4.1. Timing .........................98
3.6.3.4.2. Size and Truncation ............99
3.6.3.4.3. Constructing ...................99
3.6.3.4.4. Delayed Acknowledgement .......100
3.6.3.4.5. Obligatory Acknowledgement ....100
3.6.3.4.6. Opportunistic
Acknowledgement ...............100
3.6.3.4.7. Example .......................101
3.6.3.5. Flow Control .............................102
3.6.3.6. Receiving a Buffer Probe .................103
3.6.3.7. Rejecting a Flow .........................103
3.6.3.8. Close ....................................104
4. IANA Considerations ...........................................104
5. Security Considerations .......................................105
6. Acknowledgements ..............................................106
7. References ....................................................107
7.1. Normative References .....................................107
7.2. Informative References ...................................107
Appendix A. Example Congestion Control Algorithm .................108
A.1. Discussion ................................................108
A.2. Algorithm .................................................110
1. Introduction
Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for use as a general purpose endpoint-to-endpoint data transport service in IP networks. It has features that make it well suited to the transport of real-time media (such as low-delay video, audio, and data) as well as bulk data, and for client-server as well as peer-to- peer (P2P) communication. These features include independent parallel message flows that may have different delivery priorities, variable message reliability (from TCP-like full reliability to UDP-like best effort), multi-point congestion control, and built-in security. Session multiplexing and facilities to support UDP hole-punching simplify Network Address Translator (NAT) traversal in peer-to-peer systems. RTMFP is implemented in Flash Player, Adobe Integrated Runtime (AIR), and Adobe Media Server (AMS, formerly Flash Media Server or FMS), all from Adobe Systems Incorporated, and is used as the foundation transport protocol for real-time video, audio, and data communication, both client-server and P2P, in those products. At the time of writing, the Adobe Flash Player runtime is installed on more than one billion end-user desktop computers. RTMFP was developed by Adobe Systems Incorporated and is not the product of an IETF activity. This memo describes the syntax and operation of the Secure Real-Time Media Flow Protocol. This memo describes a general security framework that, when combined with an application-specific Cryptography Profile, can be used to establish a confidential and authenticated session between endpoints. The 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. Note to implementers: at the time of writing, the Cryptography Profile used by the above-mentioned Adobe products is not publicly described by Adobe. Implementers should investigate the availability of documentation of that Cryptography Profile prior to implementing RTMFP for the purpose of interoperation with the above-mentioned Adobe products.
1.1. Design Highlights of RTMFP
Between any pair of communicating endpoints is a single, bidirectional, secured, congestion controlled session. Unidirectional flows convey messages from one end to the other within the session. An endpoint can have concurrent sessions with multiple other far endpoints. Design highlights of RTMFP include the following: o The security framework is an inherent part of the basic protocol. The application designer chooses the cryptographic formats and algorithms to suit the needs of the application, and may update them as the state of the security arts progresses. o Cryptographic Endpoint Discriminators can resist port scanning. o All header, control, and framing information, except for network addressing information and a session identifier, is encrypted according to the Cryptography Profile. o There is a single session and associated congestion control state between a pair of endpoints. o Each session may have zero or more unidirectional message-oriented flows in each direction. All of a session's sending flows share the session's congestion control state. o Return Flow Association (Section 2.3.11.1.2) generalizes bidirectional communication to arbitrarily complex trees of flows. o Messages in flows can be arbitrarily large and are fragmented for transmission. o Messages of any size may be sent with full, partial, or no reliability (sender's choice). Messages may be delivered to the receiving user in original queuing order or network arrival order (receiver's choice). o Flows are named with arbitrary, user-defined metadata (Section 2.3.11.1.1) rather than port or stream numbers. o The sequence numbers of each flow are independent of all other flows and are not permanently bound to a session-wide transmission ordering. This allows real-time priority decisions to be made at transmission or retransmission time.
o Each flow has its own receive window and, therefore, independent
flow control.
o Round trips are expensive and are minimized or eliminated when
possible.
o After a session is established, flows begin by sending the flow's
messages with no additional handshake (and associated round
trips).
o Transmitting bytes on the network is much more expensive than
moving bytes in a CPU or memory. Wasted bytes are minimized or
eliminated when possible and practical, and variable length
encodings are used, even at the expense of breaking 32-bit
alignment and making the text diagrams in this specification look
awkward.
o P2P lookup and peer introduction (including UDP hole-punching for
NAT and firewall traversal) are supported directly by the session
startup handshake.
o Session identifiers allow an endpoint to multiplex many sessions
over a single local transport address while allowing sessions to
survive changes in transport address (as may happen in mobile or
wireless deployments).
The syntax of the protocol is detailed in Section 2. The operation
of the protocol is detailed in Section 3.
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. Syntax
Definitions of types and structures in this specification use traditional text diagrams paired with procedural descriptions using a C-like syntax. The C-like procedural descriptions SHALL be construed as definitive. Structures are packed to take only as many bytes as explicitly indicated. There is no 32-bit alignment constraint, and fields are not padded for alignment unless explicitly indicated or described. Text diagrams may include a bit ruler across the top; this is a convenience for counting bits in individual fields and does not necessarily imply field alignment on a multiple of the ruler width. Unless specified otherwise, reserved fields SHOULD be set to 0 by a sender and MUST be ignored by a receiver. The procedural syntax of this specification defines correct and error-free encoded inputs to a parser. The procedural syntax does not describe a fully featured parser, including error detection and handling. Implementations MUST include means to identify error circumstances, including truncations causing elementary or composed types to not fit inside containing structures, fields, or elements. Unless specified otherwise, an error circumstance SHALL abort the parsing and processing of an element and its enclosing elements, up to the containing packet.2.1. Common Elements
This section lists types and structures that are used throughout this specification.2.1.1. Elementary Types and Constructs
This section lists the elementary types and constructs out of which all of the following sections' definitions are built. uint8_t var; An unsigned integer 8 bits (one byte) in length and byte aligned. uint16_t var; An unsigned integer 16 bits in length, in network byte order ("big endian") and byte aligned.
uint32_t var;
An unsigned integer 32 bits in length, in network byte order and
byte aligned.
uint128_t var;
An unsigned integer 128 bits in length, in network byte order and
byte aligned.
uintn_t var :bitsize;
An unsigned integer of any other size, potentially not byte
aligned. Its size in bits is specified explicitly by bitsize.
bool_t var :1;
A boolean flag having the value true (1 or set) or false (0 or
clear) and being one bit in length.
type var[num];
A packed array of type with length num*sizeof(type)*8 bits.
struct name_t { ... } name :bitsize;
A packed structure. Its size in bits is specified by bitsize.
remainder();
The number of bytes from the current offset to the end of the
enclosing structure.
type var[remainder()];
A packed array of type, its size extending to the end of the
enclosing structure.
Note that a bitsize of "variable" indicates that the size of the
structure is determined by the sizes of its interior components. A
bitsize of "n*8" indicates that the size of the structure is a whole
number of bytes and is byte aligned.
2.1.2. Variable Length Unsigned Integer (VLU)
A VLU encodes any finite non-negative integer into one or more bytes. For each encoded byte, if the high bit is set, the next byte is also part of the VLU. If the high bit is clear, this is the final byte of the VLU. The remaining bits encode the number, seven bits at a time, from most significant to least significant. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +~+~+~+~+~+~+~+~+ +-+-+-+-+-+-+-+-+ |1| digit |...............|0| digit | +~+~+~+~+~+~+~+~+ +-+-+-+-+-+-+-+-+ ^ ^ +--------- zero or more --------+ struct vlu_t { value = 0; do { bool_t more :1; uintn_t digit :7; value = (value * 128) + digit; } while(more); } :variable*8; +-------------/-+ | \ | +-------------/-+ Figure 1: VLU Depiction in Following Diagrams Unless stated otherwise in this specification, implementations SHOULD handle VLUs encoding unsigned integers at least 64 bits in length (that is, encoding a maximum value of at least 2^64 - 1).2.1.3. Option
An Option is a Length-Type-Value triplet. Length and Type are encoded in VLU format. Length is the number of bytes of payload following the Length field. The payload comprises the Type and Value fields. Type identifies the kind of option this is. The syntax of the Value field is determined by the type of option.
An Option can have a length of zero, in which case it has no type and no value and is empty. An empty Option is called a "Marker". +-------------/-+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | length \ | type \ | value | +-------------/-+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ ^ ^ +-------- length bytes long (may be 0) ---------+ struct option_t { vlu_t length :variable*8; // "L" if(length > 0) { struct { vlu_t type :variable*8; // "T" uint8_t value[remainder()]; // "V" } payload :length*8; } } :variable*8; +---/---/-------+ | L \ T \ V | +---/---/-------+ Figure 2: Option Depiction in Following Diagrams2.1.4. Option List
An Option List is a sequence of zero or more non-empty Options terminated by a Marker. +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+ | L \ T \ V |...............| L \ T \ V | 0 \ | +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+-------------/-+ ^ ^ Marker +------- zero or more non-empty Options --------+ (empty Option) struct optionList_t { do { option_t option :variable*8; } while(option.length > 0); } :variable*8;
2.1.5. Internet Socket Address (Address)
When communicating an Internet socket address (a combination of a 32-bit IPv4 [RFC0791] or 128-bit IPv6 [RFC2460] address and a 16-bit port number) to another RTMFP, this encoding is used. This encoding additionally allows an address to be tagged with an origin type, which an RTMFP MAY use to modify the use or disposition of the address. 1 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-----/.../-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| | O | Internet | | |P|0 0 0 0 0| R | address | port | |6| rsv | I |32 or 128 bits | | +-+-+-+-+-+-+-+-+-----/.../-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ struct address_t { bool_t inet6 :1; // "IP6" uintn_t reserved :5 = 0; // "rsv" uintn_t origin :2; // "ORI" if(inet6) uint128_t ipAddress; else uint32_t ipAddress; uint16_t port; } :variable*8; inet6: If set, the Internet address is a 128-bit IPv6 address. If clear, the Internet address is a 32-bit IPv4 address. origin: The origin tag of this address. Possible values are: 0: Unknown, unspecified, or "other" 1: Address was reported by the origin as a local, directly attached interface address 2: Address was observed to be the source address from which a packet was received (a "reflexive transport address" in the terminology of [RFC5389]) 3: Address is a relay, proxy, or introducer (a Redirector and/or Forwarder)
ipAddress: The Internet address, in network byte order. port: The 16-bit port number, in network byte order.
(page 13 continued on part 2)