tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7016

Informational
Pages: 113
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     Next in Group     Group: ~adobe

Adobe's Secure Real-Time Media Flow Protocol

Part 1 of 4, p. 1 to 13
None       Next RFC Part

 


Top       ToC       Page 1 
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 Protocol

Abstract

   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.

Page 2 
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

Top      ToC       Page 3 
           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

Top      ToC       Page 4 
           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

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
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.

Top      ToC       Page 7 
   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].

Top      ToC       Page 8 
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.

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
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.

Top      ToC       Page 11 
   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 Diagrams

2.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;

Top      ToC       Page 12 
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)

Top      ToC       Page 13 
   ipAddress:  The Internet address, in network byte order.

   port:  The 16-bit port number, in network byte order.



(page 13 continued on part 2)

Next RFC Part