Skip to main content

Adobe's RTMFP Profile for Flash Communication
draft-thornburgh-rtmfp-flash-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7425.
Author Michael C. Thornburgh
Last updated 2014-05-02
RFC stream (None)
Formats
IETF conflict review conflict-review-thornburgh-rtmfp-flash, conflict-review-thornburgh-rtmfp-flash, conflict-review-thornburgh-rtmfp-flash, conflict-review-thornburgh-rtmfp-flash, conflict-review-thornburgh-rtmfp-flash, conflict-review-thornburgh-rtmfp-flash
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 7425 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-thornburgh-rtmfp-flash-01
lt;------------------------S2C-Stream-Flow-1--<--+
            |                                  :              |
            |  <------------------------S2C-Stream-Flow-M--<--+
            |
            +-->--C2S-Stream-Flow-1------------------------>
            |               :
            +-->--C2S-Stream-Flow-N------------------------>

       Figure 4: Schematic Flow Association Tree for a NetConnection

Thornburgh              Expires November 3, 2014               [Page 38]
Internet-Draft     Adobe RTMFP for Flash Communication          May 2014

5.3.5.1.  To Server

   Additional flows from the client to the server for stream messages
   are opened with the Stream ID for that stream, and associated in
   return to the server's canonical NetConnection control flow.

   The client MAY create as many flows as desired for any Stream ID
   (including Stream ID 0) at any time.

5.3.5.2.  From Server

   Additional flows from the server to the client for stream messages
   are opened with the Stream ID for that stream, and associated in
   return to the client's NetConnection control flow.

   The server MAY create as many flows as desired for any Stream ID
   (including Stream ID 0) at any time.

5.3.5.3.  Closing Stream Flows

   Either end MAY close a sending flow that is not for Stream ID 0 at
   any time with no semantic meaning for the stream.

   Either end MAY at any time reject a receiving flow that is not one of
   the other end's NetConnection control flows.  The sending end, on
   receiving an exception for a stream flow, SHOULD NOT open a new flow
   to take the rejected flow's place for transport of messages for that
   stream.  If an end rejects any flow for a stream, it SHOULD reject
   all the flows for that stream, otherwise Flow Synchronization
   messages (Section 5.2) that were in flight could be discarded and
   some flows might be stuck in a suspended state.

5.3.6.  Closing the Connection

   The client or server can signal an orderly close of the connection by
   closing its NetConnection control sending flows and all stream
   sending flows.  The other end, on receiving a close/complete
   notification for the canonical NetConnection control receiving flow,
   closes its sending flows.  When both ends observe all receiving flows
   have closed and completed, the connection has cleanly terminated.

   Either end can abruptly terminate the connection by rejecting the
   NetConnection control receiving flows, or by closing the underlying
   RTMFP session.  On notification of an exception on a NetConnection
   control sending flow, the end seeing the exception knows the other
   end has terminated abruptly, and can immediately close all sending
   and receiving flows for that connection.

Thornburgh              Expires November 3, 2014               [Page 39]
Internet-Draft     Adobe RTMFP for Flash Communication          May 2014

5.3.7.  Example

                 Client                    Server
                   |IHello (EPD:anc=URI)     |
               -+- |------------------------>|
                |  |                         |
                |  |       RHello (RCert:anc)|
          RTMFP |  |<------------------------|
         Session|  |                         |
          Hand- |  |IIKeying                 |
          shake |  |------------------------>|
                |  |                         |
                |  |                 RIKeying|
               -+- |<------------------------|
                   |                         |
               -+- |"connect" command        |
         (Str.ID=0)|-CFlow-0---------------->|
                |  |                         |
                |  |       "_result" response|
          RTMP  |  |<----------------SFlow-0-|(Str.ID=0,
         Connect|  |                         | Assoc=CFlow-0)
          Hand- |  |"setPeerInfo" command    |
          shake |  |-CFlow-0---------------->|
               -+- |                         |
                   |"createStream" command   |
               -+- |-CFlow-0---------------->|
                |  |                         |
                |  |     "_result" (str.ID=5)|
                |  |<----------------SFlow-0-|
                |  |                         |
                |  |"play" command           |
         (Str.ID=5,|-CFlow-1---------------->|
     Assoc=SFlow-0)|                         |
                |  | StreamBegin User Control|
                |  |<----------------SFlow-1-|(Str.ID=5,
                |  |                         | Assoc=CFlow-0)
                |  |  (RTMP stream events)   |
     Streaming  |  |<----------------SFlow-1-|
                |  |                         |
                |  |        Audio Data       |
                |  |<----------------SFlow-2-|(Str.ID=5,
                |  |                         | Assoc=CFlow-0)
                |  |        Video Data       |
                |  |<----------------SFlow-3-|(Str.ID=5,
                |  |            :            | Assoc=CFlow-0)
                   |            :            |

             Figure 5: Example NetConnection Message Exchange

Thornburgh              Expires November 3, 2014               [Page 40]
Internet-Draft     Adobe RTMFP for Flash Communication          May 2014

5.4.  Direct Peer to Peer Streams

   Clients can connect directly to other clients for peer-to-peer (P2P)
   streaming and data exchange.  A client MAY have multiple separate P2P
   NetStreams with a peer in one RTMFP session, each a separate logical
   connection.  P2P NetStreams are unidirectional, initiated by a
   subscriber (the side issuing the "play" command") to a publisher.
   The subscribing peer has a control flow to the publisher.  The
   publisher has zero or more return flows to the subscriber, associated
   to the subscriber's control flow, for the stream media and data.

5.4.1.  Connecting

   A client desires to subscribe directly to a stream being published in
   P2P mode by a publishing peer.  The client learns the peer ID of the
   publisher and the stream name through application-specific means.

   If the client does not already have an RTMFP session with that peer
   ID, it initiates a new session, creating an EPD containing a
   Fingerprint option (Section 4.4.2.3) for the publisher's peer ID and
   using the server session's DESTADDR as the initial candidate address
   for the session to the peer.  The server acts as an Introducer
   (Section 3.5.1.6 of RFC 7016), using forward and redirect messages to
   help the client and the peer establish a session.

   When an S_OPEN session exists to the desired peer, the client creates
   a new independent flow to that peer.  The flow MUST have a non-zero
   Stream ID.  The client sends an RTMP "play" command over the flow,
   giving the name of the desired stream at the publisher.  This flow is
   the subscriber's control flow.

5.4.2.  Return Flows for Stream

   The publisher, on accepting a new flow not indicating a return
   association with any of its sending flows and having a non-zero
   Stream ID, receives and processes the "play" command.  If and when
   the request is acceptable to the publisher, it opens one or more
   return flows to the subscribing peer, associated to the subscriber's
   control flow and having the same Stream ID.  The publisher sends a
   StreamBegin User Control message, appropriate RTMP status events, and
   the stream media over the one or more return flows.

   The subscriber uses the return association of the media flows to the
   subscriber control flow to determine the stream to which the media
   belongs.

   The publisher MAY open any number of media flows for the stream, and
   close them at any time.  The opening and closing of media flows has

Thornburgh              Expires November 3, 2014               [Page 41]
Internet-Draft     Adobe RTMFP for Flash Communication          May 2014

   no semantic meaning for the stream, except that the opening of at
   least one flow and the reception of at least one media message or a
   StreamBegin User Control message indicates that the publisher is
   publishing the requested stream to the subscriber.

         Subscriber                                     Publisher
         ------>--Subscriber-Control-Flow------------------>--+
                                                              |
               <------------------Publisher-Stream-Flow-1--<--+
                                              :               |
               <------------------Publisher-Stream-Flow-N--<--+

   Figure 6: Schematic Flow Association Tree for a P2P Direct Connection

5.4.3.  Closing the Connection

   Either end can close the stream by closing or rejecting the
   subscriber's control flow.  The publisher SHOULD close and unpublish
   to the subscriber on receipt of a close/complete of the control flow.
   The subscriber SHOULD consider the stream closed on notification of
   an exception on the control flow.

6.  IANA Considerations

   This memo specifies option type code values for Certificate fields
   (Section 4.3.3), Endpoint Discriminator fields (Section 4.4.2), and
   Session Keying Component fields (Section 4.5.2), and specifies a flow
   metadata signature (Section 5.1.1).  The type code values and
   signatures for this profile are assigned and maintained by Adobe.
   Therefore, this memo has no IANA actions.

7.  Security Considerations

   Section 4 details the cryptographic aspects of this profile.

   This profile does not define or use a Public Key Infrastructure
   (PKI).  Clients SHOULD use static Diffie-Hellman keys in their
   certificates (Section 4.3.3.5).  Clients MUST create a new
   certificate with a distinct fingerprint for each new NetConnection
   (Section 5.3).  These constraints make client identities ephemeral
   but unable to be forged.

   Servers can have long-lived RTMFP instances, so they SHOULD use
   ephemeral Diffie-Hellman public keys for forward secrecy.  This
   allows server peer IDs to be forged; however, clients do not connect
   to servers by peer ID, so this is irrelevant.

Thornburgh              Expires November 3, 2014               [Page 42]
Internet-Draft     Adobe RTMFP for Flash Communication          May 2014

   When a client connects to a server, the client will accept the
   response of any endpoint claiming to be "a server".  It is assumed
   that an attacker that can passively observe traffic on a network
   segment can also inject its own packets with any source or
   destination and any payload.  An attacker can trick a client into
   connecting to a rogue server, either by observing Initiator Hello
   packets from the client and responding with a matching Responder
   Hello, or by using tricks such as DNS spoofing or poisoning to direct
   a client to connect directly to the rogue server.  Any TCP-based
   transport would be vulnerable to similar attacks.  Since there is no
   PKI, this profile gives no guarantee that the client has actually
   connected to the desired server.  In circumstances where assurance is
   required that the connection is to the desired server, the client can
   use the Session Nonces (Section 4.6.5) to challenge the server, for
   example with secret information obtained over a different channel
   having acceptable security properties (such as an HTTPS), to
   transitively establish the server's identity and verify that the end-
   to-end communication is private and authentic.

   When Session Sequence Numbers (Section 4.7.3.3) are not used, it is
   possible for an attacker to use traffic analysis techniques and
   record encrypted packets containing the start of a new flow, and
   later to replay those packets after the flow has closed, which can
   look to the receiver like a brand new flow.  In circumstances where
   this can be detrimental, Session Sequence Numbers SHOULD be used.
   Replay of packets for existing flows is not detrimental as the
   receiver detects and discards duplicate flow sequence numbers, and
   flow sequence numbers do not wrap or otherwise repeat.

   Packet encryption uses CBC with the same (null) initialization vector
   for each packet.  This can reveal to an observer whether two packets
   contain identical plaintext.  However, the maximum-length RTMFP
   common header and User Data or Data Acknowledgement header, including
   flow sequence number, always fit within the first 16-byte cipher
   block, so each initial cipher block for most packets will already be
   unique even if timestamps are suppressed.  Sending identical messages
   in a flow uses unique flow sequence numbers, so cipher blocks will be
   unique in this case.  Keepalive pings and retransmission of lost data
   can result in identical cipher blocks; however, traffic analysis can
   also reveal likely keepalives or retransmissions, and retransmission
   only occurs as a result of observable network loss, so this is
   usually irrelevant.  In circumstances where any identical cipher
   block is unacceptable, Session Sequence Numbers SHOULD be used as
   they guarantee each initial cipher block will be unique.

   Packet verification can use a 16-bit simple checksum
   (Section 4.7.3.1).  The checksum is inside the encrypted packet, so
   for external packet modifications the checksum is equivalent to a

Thornburgh              Expires November 3, 2014               [Page 43]
Internet-Draft     Adobe RTMFP for Flash Communication          May 2014

   16-bit cryptographic digest.  In circumstances where this is
   insufficient, HMAC verification (Section 4.7.3.2) SHOULD be used.

8.  Acknowledgements

   Special thanks go to Adam Lane, Glenn Eguchi, and Matthew Kaufman for
   their contributions to the design of this profile.

   Thanks to Philipp Hancke for his detailed review of this memo.

9.  References

9.1.  Normative References

   [AES]      United States of America, National Institute of Standards
              and Technology, "Advanced Encryption Standard", Federal
              Information Processing Standard (FIPS) 197, November 2001,
              <http://csrc.nist.gov/publications/fips/fips197/
              fips-197.pdf>.

   [AMF0]     Adobe Systems Incorporated, "Action Message Format -- AMF
              0", December 2007, <http://opensource.adobe.com/wiki/
              download/attachments/1114283/amf0_spec_121207.pdf>.

   [AMF3]     Adobe Systems Incorporated, "Action Message Format -- AMF
              3", May 2008, <http://opensource.adobe.com/wiki/download/
              attachments/1114283/amf3_spec_05_05_08.pdf>.

   [CBC]      Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation", NIST Special Publication 800-38A, December
              2001, <http://csrc.nist.gov/publications/nistpubs/800-38a/
              sp800-38a.pdf>.

   [DH]       Diffie, W. and M. Hellman, "New Directions in
              Cryptography", IEEE Transactions on Information Theory, V.
              IT-22, n. 6, June 1977.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, May 2003.

Thornburgh              Expires November 3, 2014               [Page 44]
Internet-Draft     Adobe RTMFP for Flash Communication          May 2014

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
              5996, September 2010.

   [RFC6234]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

   [RFC7016]  Thornburgh, M., "Adobe's Secure Real-Time Media Flow
              Protocol", RFC 7016, November 2013.

   [RTMP]     Adobe Systems Incorporated, "Real-Time Messaging Protocol
              (RTMP) specification", June 2009,
              <http://www.adobe.com/devnet/rtmp/>.

   [SHA256]   United States of America, National Institute of Standards
              and Technology, "Secure Hash Standard", Federal
              Information Processing Standard (FIPS) 180-2, August 2002,
              <http://csrc.nist.gov/publications/fips/fips180-2/
              fips180-2withchangenotice.pdf>.

9.2.  Informative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1071]  Braden, R., Borman, D., Partridge, C., and W. Plummer,
              "Computing the Internet checksum", RFC 1071, September
              1988.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [RFC6479]  Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm
              without Bit Shifting", RFC 6479, January 2012.

Thornburgh              Expires November 3, 2014               [Page 45]
Internet-Draft     Adobe RTMFP for Flash Communication          May 2014

Author's Address

   Michael C. Thornburgh
   Adobe Systems Incorporated
   345 Park Avenue
   San Jose, CA  95110-2704
   US

   Phone: +1 408 536 6000
   Email: mthornbu@adobe.com
   URI:   http://www.adobe.com/

Thornburgh              Expires November 3, 2014               [Page 46]