RFC 7425
Adobe's RTMFP Profile for Flash Communication
Pages: 49
Informational
Informational
Part 2 of 2 – Pages 31 to 49
5. Flash Communication
The Flash platform uses RTMP [RTMP] messages for media streaming and communication. This section describes how to transport RTMP messages over RTMFP flows and additional messages and semantics unique to this transport.5.1. RTMP Messages
An RTMP message comprises a virtual header and a payload. The virtual header comprises a Message Type, a Payload Length, a Timestamp, and a Stream ID. The format of the payload is dependent on the type of message. An RTMP message is mapped onto a lower transport layer, such as RTMP Chunk Stream [RTMP] or RTMFP. RTMP messages were initially designed along with, and for transport on, RTMP Chunk Stream. This design constrains the possible values of RTMP message header fields. In particular:
Message Type is 8 bits wide, and is therefore constrained to
values from 0 to 255 inclusive;
Payload Length is 24 bits wide, so messages can be at most
16777215 bytes long;
Timestamp is 32 bits wide, so timestamps range from 0 to
4294967295 and wrap around;
Stream ID is 24 bits wide, and is therefore constrained to values
from 0 to 16777215 inclusive.
RTMP Chunk Stream Protocol Control messages (message types 1, 2, 3,
5, and 6) are not used when transporting RTMP messages in RTMFP
flows. Messages of those types SHOULD NOT be sent and MUST be
ignored.
5.1.1. Flow Metadata
All messages in RTMFP are transported in flows. In this profile, an
RTMFP flow for RTMP messages carries the messages for exactly one
RTMP Stream ID. Multiple flows can carry messages for the same
Stream ID; for example, the video and audio messages of a stream
could be sent on separate flows, allowing the audio to be given
higher transmission priority.
The User Metadata for flows in this profile begins with a distinct
signature to distinguish among different kinds of flows. The User
Metadata for a flow used for RTMP messages begins with the two-
character signature "TC".
The Stream ID is encoded in the flow's User Metadata so that it
doesn't need to be sent with each message.
The sender can have a priori knowledge about the kind of media it
intends to send on a flow and its intended use and can give the
receiver a hint as to whether messages should be delivered as soon as
possible or in their original queuing order. For example, the sender
might be sending real-time, delay-sensitive audio messages on a flow,
and hint that the receiver should take delivery of the messages on
that flow as soon as they arrive in the network, to reduce the end-
to-end latency of the audio.
The receiver can choose to take delivery of messages on flows as soon
as they arrive in the network or in the messages' original queuing
order. A receiver that chooses to take delivery of messages as soon
as they arrive in the network MUST be prepared for the messages to
arrive out-of-order. For example, a receiver may choose not to
render a newly received audio message having a timestamp earlier than
the most recently rendered audio timestamp.
The sender can choose to abandon a message that it has queued in a
flow before the message has been delivered to the receiver. For
example, the sender may abandon a real-time, delay-sensitive audio
message that has not been delivered within one second, to avoid
spending transmission resources on stale media that is no longer
relevant.
Note: A gap will cause a delay at the receiver of at least one round-
trip time if the receiver is taking delivery of messages in original
queuing order.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~~~~~~~~~~~~~/~+
| | | |S|r|R| \ |
| 0x54 'T' | 0x43 'C' | rsv |I|s|X| streamID / |
| | | |D|v|I| \ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~~~~~~~~~~~~~/~+
struct RTMPMetadata_t
{
uint8_t signature[2] == { 'T', 'C' };
uintn_t reserved1 :5; // rsv
bool_t streamIDPresent :1; // SID
uintn_t reserved2 :1; // rsv
uintn_t receiveIntent :1; // RXI
// 0: original queuing order, 1: network arrival order
if(streamIDPresent)
vlu_t streamID :variable*8;
} :variable*8;
signature: Metadata signature for RTMP message flows, being the two
UTF-8 coded characters "TC".
streamIDPresent: A boolean flag indicating whether the streamID
field is present. In this profile, this flag MUST be set.
receiveIntent: A hint by the sender as to the best order in which to
take delivery of messages from the flow. A value of zero
indicates a hint that the flow's messages should be received in
the order they were originally queued by the sender (that is, in
ascending sequence number order); a value of one indicates a hint
that the flow's messages should be received in the order they
arrive in the network, even if there are sequence number gaps or
reordering. Network arrival order is typically hinted for live,
delay-sensitive flows, such as for audio media. To take delivery
of a message as soon as it arrives in the network: receive it from
the receiving flow's RECV_BUFFER as soon as it becomes complete
(Section 3.6.3.3 of RFC 7016), and remove it from the RECV_BUFFER.
Section 3.6.3.3 of RFC 7016 describes how to take delivery of
messages in original queuing order.
streamID: If the streamIDPresent flag is set, this field is present
and is the RTMP stream ID to which the messages in this flow
belong. In this profile, this field MUST be present.
A receiver SHOULD reject an RTMP message flow if its streamIDPresent
flag is clear. This profile doesn't define a stream mapping for this
case.
Derived or composed profiles can define additional flow types and
corresponding metadata signatures. A receiver SHOULD reject a flow
having an unrecognized metadata signature.
5.1.2. Message Mapping
This section describes the format of an RTMP message (Section 5.1) in
an RTMFP flow.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| messageType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| messagePayload |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
struct RTMPMessage_t
{
uint8_t messageType;
uint32_t timestamp;
uint8_t messagePayload[remainder()];
} :flowMessageLength*8;
messageType: The RTMP Message Type;
timestamp: The RTMP Timestamp, in network byte order;
messagePayload: The payload of the RTMP message;
payload length: The RTMP message payload length is inferred from the
length of the RTMFP message;
Stream ID: The Stream ID for this message is taken from the metadata
of the flow on which this message was received.
5.2. Flow Synchronization
RTMFP flows are independent and have no inter-flow ordering
guarantee. RTMP was designed for transport over a single, reliable,
strictly ordered byte stream. Some RTMP message semantics take
advantage of this ordering; for example, a Stream EOF User Control
event must not be processed until after all media messages for the
corresponding stream have been received. Flow Synchronization
messages provide a barrier to align message delivery across flows
when required by RTMP semantics.
A Flow Synchronization message is coded as a User Control event
message (Type 4) having Event Type 34. Message timestamps are
ignored and MAY be set to 0.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| eventType = 34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| syncID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct flowSyncUserControlMessagePayload_t
{
uint16_t eventType = 34;
uint32_t syncID;
uint32_t count;
} :10*8;
eventType: The RTMP User Control Message Event Type. Flow
Synchronization messages have type 34 (0x22);
syncID: The identifier for this barrier;
count: The number of flows being synchronized by syncID. This field
MUST be at least 1 and SHOULD be at least 2.
On receipt of a Flow Synchronization message, a receiver SHOULD suspend receipt of further messages on that flow until count Flow Synchronization messages (including this one) with the same syncID have been received on flows in the same flow association tree. Example: Consider flows F1 and F2 in the same NetConnection carrying messages M, and let Sync(syncID,count) denote a Flow Synchronization message. | | F1: M1 M2 M4 Sync(8,2) | Sync(13,2).....| M7 | | F2: M3 Sync(8,2).......| M5 Sync(13,2) | M6 | | Barrier 8 Barrier 13 Figure 2: Example Flow Synchronization Barriers Flow Synchronization messages form a delivery barrier to impart at least a partial message ordering across flows. In this example, message M5 comes after M1..4 and before M6..7; however, M3 could be delivered before or after any of M1, M2, or M4, and M6 could come before or after M7. Flow Synchronization can cause a priority inversion; therefore, it SHOULD NOT be used except when necessary to preserve RTMP ordering semantics.5.3. Client-to-Server Connection
The client connects to a server. The connection comprises one main control flow in each direction from client to server and from server to client for NetConnection messages, and zero or more flows in each direction for NetStream media messages. NetStream flows may come and go naturally over time according to media transport needs. An exception on a NetConnection control sending flow indicates the closure by the other end of the NetConnection and all associated NetStreams. The client MUST NOT use the same client certificate for more than one server connection; that is, a client's peer ID MUST NOT be reused.5.3.1. Connecting
The client desires a connection to a server having an RTMFP URI, for example, "rtmfp://server.example.com/app/instance". The client gathers one or more initial candidate addresses for the server named in the URI (for example, by using the Domain Name System (DNS)
[RFC1035]). The client creates an EPD having an Ancillary Data option (Section 4.4.2.2) encoding the URI. The client initiates an RTMFP session to the one or more candidate addresses using the EPD. When the session transitions to the S_OPEN state, the client opens a new flow in that session for Stream ID 0 and Receive Intent 0 "original queuing order". This is the client's NetConnection main control flow. The client sends an RTMP "connect" command on the flow and waits for a response or exception.5.3.2. Server-to-Client Return Control Flow
The server, on accepting the client's NetConnection control flow, and receiving and accepting the "connect" command, opens one or more return flows to the client having Stream ID 0 and associated to the control flow from the client. Flows for Stream ID 0 are the server's NetConnection control flows. The server sends a "_result" or "_error" transaction response for the client's connect command. When the client receives the first return flow from the server for Stream ID 0 and associated to the client's NetConnection control flow, the client assumes that flow is the canonical return NetConnection control flow from the server, to which all new client- to-server flows should be associated. On receipt of a "_result" transaction response on Stream ID 0 for the client's connect command, the connection is up. The client MAY open additional return control flows to the server on Stream ID 0, associated to the server's canonical NetConnection control flow.5.3.3. setPeerInfo Command
The "setPeerInfo" command is sent by the client to the server over the NetConnection control flow to inform the server of candidate socket addresses through which the client might be reachable. This list SHOULD include all directly connected interface addresses and proxy addresses except as provided below. The list MAY be empty. The list need not include the address of the server, even if the server is to act as an introducer for the client. The list SHOULD NOT include link-local or loopback addresses. This command is sent as a regular RTMP NetConnection command; that is, as an RTMP Type 20 Command Message or an RTMP Type 17 Command Extended Message on Stream ID 0. A Type 20 Command Message SHOULD be used if the object encoding negotiated during the "connect" and
"_result" handshake is AMF0 [AMF0], and a Type 17 Command Extended Message SHOULD be used if the negotiated object encoding is AMF3 [AMF3]. Note: A Type 20 Command Message payload is a sequence of AMF objects encoded in AMF0. Note: A Type 17 Command Extended Message payload begins with a format selector byte, followed by a sequence of objects in a format-specific encoding. At the time of writing, only format 0 is defined; therefore, the format selector byte MUST be 0. Format 0 is a sequence of AMF objects, each encoded in AMF0 by default; AMF3 encoding for an object can be selected by prefixing it with an "avmplus-object-marker" (0x11) as defined in [AMF0]. To complete the RTMFP NetConnection handshake, an RTMFP client MUST send a setPeerInfo command to the server after receiving a successful response to the "connect" command. ( "setPeerInfo", // AMF String, command name 0.0, // AMF Number, transaction ID NULL, // AMF Null, no command object ... // zero or more AMF Strings, each an address ) Each listed socket address includes an IPv4 or IPv6 address in presentation format and a UDP port number in decimal, separated by a colon. Since the IPv6 address presentation format uses colons, IPv6 addresses are enclosed in square brackets [RFC3986]. ( "setPeerInfo", 0.0, NULL, "192.0.2.129:50001", "[2001:db8:1::2]:50002" ) Figure 3: Example setPeerInfo Command A server SHOULD assume that the client is behind a Network Address Translator (NAT) if and only if the observed far endpoint address of the session for the flow on which this command was received does not appear in the setPeerInfo address list.
5.3.4. Set Keepalive Timers Command
The server can advise the client to set or change the client's session keepalive timer periods for its connection to the server and for its P2P connections. The server MAY choose keepalive periods based on static configuration, application- or deployment-specific circumstances, whether the client appears to be behind a NAT, or for any other reason. The Set Keepalive Timers command is sent by the server to the client on Stream ID 0 as a User Control event message (Type 4) having Event Type 41. Message timestamps are ignored and MAY be set to 0. 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | eventType = 41 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | serverKeepalivePeriodMsec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | peerKeepalivePeriodMsec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ struct setKeepaliveUserControlMessagePayload_t { uint16_t eventType = 41; uint32_t serverKeepalivePeriodMsec; uint32_t peerKeepalivePeriodMsec; } :10*8; eventType: The RTMP User Control Message Event Type. Set Keepalive Timers messages have type 41 (0x29); serverKeepalivePeriodMsec: The keepalive period, in milliseconds, that the client is advised to set on its RTMFP session with the server; peerKeepalivePeriodMsec: The keepalive period, in milliseconds, that the client is advised to use on its RTMFP sessions with any peer that is not the server.
The client MUST define minimum values for these keepalive periods, below which it will not set them, regardless of the values in this message. The minimum keepalive timer periods SHOULD be at least five seconds. The client MAY define maximum values for these keepalive periods, above which it will not set them. On receipt of this message from the server, a client SHOULD set its RTMFP server and peer keepalive timer periods to the indicated values subject to the client's minimum and maximum values. The server MAY send this message more than once, particularly if conditions that it uses to determine the timer periods change.5.3.5. Additional Flows for Streams
The client or server opens additional flows to the other side to carry messages for any stream. Additional flows are associated to the canonical NetConnection control flow from the other side. Client Server ------>--C2S-Control-Flow------------------------->--+ | +--<------------------------S2C-Control-Flow---<--+ | | | <------------------------S2C-Stream-Flow-1--<--+ | : | | <------------------------S2C-Stream-Flow-M--<--+ | +-->--C2S-Stream-Flow-1------------------------> | : +-->--C2S-Stream-Flow-N------------------------> Figure 4: Schematic Flow Association Tree for a NetConnection5.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. At any time, either end MAY reject a receiving flow that is not one of the other end's NetConnection control flows. No flow exception codes are defined by this profile, so the receiving end SHOULD use exception code 0 when rejecting the flow. The sending end, on notification of any 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 become or remain 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 any 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.
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
5.4. Direct Peer-to-Peer Streams
Clients can connect directly to other clients for 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 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 Connection5.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 any 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). It also specifies a flow metadata signature (Section 5.1.1). The type code values and signatures for this profile are assigned and maintained by Adobe, and therefore require no action from IANA.6.1. RTMFP URI Scheme Registration
This memo describes use of an RTMFP URI scheme (Section 4.4.2.2, Section 5.3.1, Figure 5). Per this section, the "rtmfp" URI scheme has been registered by IANA. The syntax and semantics of this URI scheme are described using the Augmented Backus-Naur Form (ABNF) [RFC5234] rules from RFC 3986.
URI scheme name: rtmfp
Status: provisional
URI scheme syntax:
rtmfp-uri-scheme = "rtmfp:"
/ "rtmfp://" host [ ":" port ] path-abempty
URI scheme semantics: The first form is used in the APIs of some
implementations to indicate instantiation of an RTMFP client
according to this memo, but without connecting to a server. Such
an instantiation might be used for pure peer-to-peer
communication.
The second form provides location information for the server to
which to connect and optional additional information to pass to
the server. The only operation for this URI form is to connect to
a server (initial candidate address(es) for which are named by
host and port) according to Section 5.3. The UDP port for initial
candidate addresses, if not specified, is 1935. If the host is a
reg-name, the initial candidate address set SHOULD comprise all
IPv4 and IPv6 addresses to which reg-name resolves. The semantics
of path-abempty are specific to the server. Connections are made
using RTMFP as specified by this memo.
Encoding considerations: The path-abempty component represents
textual data consisting of characters from the Universal Character
Set. This component SHOULD be encoded according to Section 2.5 of
RFC 3986.
Applications/protocols that use this URI scheme name: The Flash
runtime (including Flash Player) from Adobe Systems Incorporated,
communication servers such as Adobe Media Server, and
interoperable clients and servers provided by other parties, using
RTMFP according to this memo.
Interoperability considerations: This scheme requires use of RTMFP
as defined by RFC 7016 in the manner described by this memo.
Security considerations: See Security Considerations (Section 7) in
this memo.
Contact: Michael Thornburgh, Adobe Systems Incorporated,
<mthornbu@adobe.com>.
Author/Change controller: Michael Thornburgh, Adobe Systems
Incorporated, <mthornbu@adobe.com>.
References:
Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol",
RFC 7016, November 2013.
This memo.
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. A man-in-the-middle cannot successfully
interpose itself in a connection to a target client addressed by its
fingerprint/peer ID if the target client uses a static Diffie-Hellman
public key.
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.
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 or man-in-the-middle, either by
observing Initiator Hello packets from the client and responding
earliest 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. A 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, versus a
rogue or man-in-the-middle. In circumstances where assurance is
required that the connection is directly to the desired server, the
client can use the Session Nonces (Section 4.6.5) to challenge the
server, for example, 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 16-bit cryptographic digest. In circumstances where this is insufficient, HMAC verification (Section 4.7.3.2) SHOULD be used.8. References
8.1. Normative References
[AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 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://www.adobe.com/go/spec_amf0>. [AMF3] Adobe Systems Incorporated, "Action Message Format -- AMF 3", January 2013, <http://www.adobe.com/go/spec_amf3>. [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, <http://www.rfc-editor.org/info/rfc2104>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003, <http://www.rfc-editor.org/info/rfc3526>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>. [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>. [RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol", RFC 7016, November 2013, <http://www.rfc-editor.org/info/rfc7016>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>. [RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol (RTMP) specification", December 2012, <http://www.adobe.com/go/spec_rtmp>.
[SHA256] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.8.2. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>. [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988, <http://www.rfc-editor.org/info/rfc1071>. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>. [RFC6479] Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm without Bit Shifting", RFC 6479, January 2012, <http://www.rfc-editor.org/info/rfc6479>.Acknowledgements
Special thanks go to Glenn Eguchi, Matthew Kaufman, and Adam Lane for their contributions to the design of this profile. Thanks to Philipp Hancke, Kevin Igoe, Paul Kyzivat, and Milos Trboljevac for their detailed reviews of this memo.Author's Address
Michael C. Thornburgh Adobe Systems Incorporated 345 Park Avenue San Jose, CA 95110-2704 United States Phone: +1 408 536 6000 EMail: mthornbu@adobe.com URI: http://www.adobe.com/