UFTP - Encrypted UDP based FTP with multicast 1. Introduction A UFTP session consists of 3 main phases: The Announce/Register phase, the File Transfer phase, and the Completion/Confirmation phase. The File Transfer phase additionally consists of the File Info phase and the Data Transfer phase for each file sent. The Announce/Register phase sets up the multicast file transfer session and negotiates all encryption parameters. The server sends out an announcement over a public multicast address which the clients are expected to be listening on. All subsequent messages from the server go over a private multicast address specified in the announcement. Allowed clients send a registration to respond to the announcement. The server will then send either a confirmation message if encryption is disabled, or the encryption keys for the session if encryption is enabled. If the client receives the encryption keys, it sends an acknowledgment back to the server. The File Transfer phase starts with the File Info phase for the first file to send. The server sends a message describing the file in question. Besides the name and size of the file, this message describes how the file will be broken down. A file is divided into a number of blocks, and these blocks are grouped into sections. A block is a piece of the file that is sent in a single packet, and a section is a grouping of blocks. The total number of blocks and sections is included in this message. Continuing the File Transfer phase is the Data Transfer phase for the first file. Data packets, each of which is a block, are sent by the server at a rate specified by the user. Because UDP does not guarantee that packets will arrive in order, each block is numbered so the client can properly reassemble the file. When the server has finished sending all data packets, it sends a message to the clients indicating this. When a client detects the end of a section or receives an end of file message from the server, and the client has detected one or more missing blocks, the client will send back a message containing a list of NAKs (negative acknowledgments). When the server receives NAKs from one or more clients, it goes back and retransmits any blocks that were NAKed, then continues on sending any untransmitted blocks. When a client has received the entire file, it sends a completion message in response to the server's end of file message. This continues until all clients have either send a completion message or have timed out after the server sent its end of file message. The File Info phase and the Data Transfer phase are then repeated for each file to be sent during the session. The Completion/Confirmation phase shuts down the session between the server and clients. It starts with a message from the server indication the end of the session. The clients then respond with a completion message, and the server responds to each completion with a confirmation message. 2. Definitions Server: A process run on demand that sends one or more files. Client: Daemon process that receives files. Public multicast address: A multicast address that a client or proxy expects to receive announcements from a server on. Private multicast address: Specified by the server when a session is initiated. All traffic from the server other than announcements are sent to this address. Proxy: Daemon process that relays UFTP traffic between servers and clients. Server proxy: A proxy, typically local to a server, that forms the upstream end of a multicast tunnel. It listens on the public multicast address (and private multicast address when specified) and forwards downstream packets to a specific address downstream. Upstream packets are forwarded back where the announcement originated from. Client proxy: A proxy, typically local to one or more clients, that forms the downstream end of a multicast tunnel. It receives unicast data from one or more server proxies and forwards downstream traffic to the multicast address specified in the packet header. Upstream traffic from clients is gathered and forwarded back where the announcement came from as an aggregated response. Response proxy: A proxy that functions as a response aggregator in situations where the server has direct multicast accessibility to clients but the number of clients are to high for the server to handle itself. It listens on the public multicast address (and private multicast address when specified), but does not forward packets from the server since those packets reach clients directly. It does however send some messages directly to clients in the process of establishing encryption keys. Upstream traffic from clients is gathered and forwarded back where the announcement came from as an aggregated response. Clients in this environment are configured to send all responses to a specific response proxy. Messages sent directly from response proxies to clients use multicast (either the primary public address, or the private address, depending on the message). Block: A piece of a file to be sent in a single packet. Section: A grouping of blocks. A section of blocks is the most the server can send before requesting status from a client. A client can send back a single status message to represent the NAKs for an entire section. 3. Timing 3.1 Round Trip Timing The server measures the round trip time (RTT) to each of the clients in order to determine the proper retransmission timing. In an ANNOUNCE, the server includes a timestamp. This timestamp is echoed back in the REGISTER sent by each client, adjusted by the time between when the client received the ANNOUNCE and when it sent the REGISTER. The server then takes the difference between the time in the REGISTER and the current time as the RTT to that client. The server keeps track of the group round trip time (GRTT) which is advertised to the clients in each message sent by the server. On the initial announce, this is set to a reasonable default. Once RTTs for the clients have been measured, the largest of the individual RTTs becomes the GRTT. After the GRTT has been set once based on the RTTs of one or more clients, any subsequent adjustments have a floor of 0.9 times the prior value (RFC 5401). 3.2 Message Timing The GRTT is used to determine the timing of message retransmissions in both directions. A message robustness factor (ROBUST) is used as part of the timing calculations. This value is also sent to the clients in an ANNOUCE so that both server and clients will use a common value. The server will wait 3 * GRTT between each group of ANNOUNCE, REGCONF, KEYINFO, and FILEINFO messages sent before sending the next set. Clients should normally respond in the (1 * GRTT -- 2 * GRTT) time window. An extra GRTT is added to this to allow for a proxy to aggregate client messages and pass them on. Once all clients have responded during a given phase, the server will wait 1 * GRTT for any late responses before ending the phase. During the Announce/Register and File Info phases, the server will send the relevant messages a maximum of ROBUST times, after which clients that have not responded will be marked as dropped. When a client detects that a new section has started, or upon receiving a DONE, it start a timer lasting 1 * GRTT. When this timer triggers, the client will send a STATUS for each section containing a NAK up to the last section completed, or up to the section specified in a DONE. When the server receives a STATUS message from a client, it first checks if the section listed in the STATUS is prior to the current transmission section. If not, it is ignored, otherwise the NAKs are recorded for retransmission. The server will then (at the end of the current pass of data, and if it hasn't done so already) start a timer lasting 3 * GRTT. When this timer expires, the server will rewind its transmission position to the earliest recorded NAK. When the server reaches the end of data transmission, it will send DONE messages every 3 * GRTT up to a maximum of ROBUST times to prompt clients to send a COMPLETE or STATUS. This continues until all clients respond with a COMPLETE, at least one client responds with a STATUS in which case it will set the rewind timer as above, or ROBUST DONEs are sent in which case any client that didn't respond with a DONE is marked as lost. TODO: Enter a holdoff period like NORM and add later NAKs? After a client sends a REGISTER, it will be retransmitted every 5 * GRTT with a maximum time of 5 * ROBUST * GRTT, after which the client drops the session. During the Completion/Confirmation stage, the client will retransmit a COMPLETE every 4 * GRTT with a maximum of ROBUST * GRTT, after which the client considers the session complete and does the normal cleanup. During the Data Transfer phase, if there are no packets received in ROBUST * GRTT, the client drops the session. In all cases, the maximum time is no less than one second. When a proxy receives a REGISTER, FILEINFO_ACK, STATUS, or COMPLETE from a client, it will wait for 1 * GRTT for any related messages before sending an aggregated response to the server. The proxy can also send a KEYINFO to one or more clients. It will wait 2 * GRTT for responses before resending. When a proxy has no pending aggregated messages to send, it will time out the session if no packets have been received in 4 * ROBUST * GRTT. When sending an aggregated REGISTER or FILEINFO_ACK message, a proxy will note which client reported the longest RTT based on the echoed timestamp and will include that client's timestamp in the response. That client will also be listed first in the body of the message so the server may determine which individual client has the longest RTT. TODO: Figure out if we want the server to send one message per cycle or one group of messages per cycle. The former will help manage message implosion but will take longer, while the later is quicker but more prone to message implosion, and is the way version 3.x does it. 3.3 Congestion Control A congestion control scheme based on TFMCC (RFC 4654) is employed. To comply with this, each data packet includes a sequence number (cc_seq) and the current congestion control rate (cc_rate). A separate CONG_CTRL message will also be sent once per GRTT. This message also contains cc_seq and cc_rate along with a timestamp for RTT measurements and a list of receivers along with the RTT and a set of flags for each. Receivers send back CC_ACK messages periodically in accordance with RFC 4654. The TFMCC specific info in this message is included as a header extension. This extension is also included in STATUS messages. When a proxy prepares to send an aggregated STATUS message, it determines the current limiting receiver (CLR) among the clients that contributed to the aggregated message and forwards that client's congestion control info along with the STATUS message. Proxies will not aggregate CC_ACK messages and will forward them on immediately, adjusting the echoed timestamp as necessary. 4. Encryption Setup 4.1 General The key exchange / encryption protocol borrows from TLS 1.3 (RFC8446). Due to the large amount of traffic that may be generated while communicating with a large number of clients, the required key exchange messages are made as small as possible and integrated into the UFTP messaging structure to minimize the amount of traffic in the setup phase. All supported symmetric ciphers use Authenticated Encryption with Associated Data (AEAD) algorithms. The supported ciphers are AES-128 and AES-256 in either GCM or CCM mode. For the block encryption algorithm chosen, there are: key_length iv_length AES-128-GCM 16 12 AES-128-CCM 16 12 AES-256-GCM 32 12 AES-256-CCM 32 12 Supported hash algorithms are SHA-256, SHA-384, and SHA-512. For the hash algorithm chosen, there is: hash_len SHA-256 32 SHA-384 48 SHA-512 64 Authentication of encrypted messages is performed by using an AEAD symmetric cipher. For each message to be encrypted, an IV must be generated as follows: IV = S XOR CTR where CTR is a monotonically increasing 64-bit counter and S is a salt hash_len bytes long, derived below. Key derivation is performed using HKDF-Extract and HDKF-Expand as defined in HKDF(RFC5869). It also uses a modified version of HDKF-Expand-Label defined in TLS 1.3 as follows: HKDF-Expand-Label(Secret, Label, Context, Length) = HKDF-Expand(Secret, HkdfLabel, Length) Where HkdfLabel is specified as: "UFTP5 " + Label + Context These functions use the hash algorithm specified by the server. During the initial setup, there is an exchange of symmetric keys between the server and each client. This is done using an Elliptic Curve Diffie-Hellman (ECDH) key exchange. The key exchange parameters are validated with either RSA signatures or Elliptic Curve DSA (ECDSA) signatures. All messages to be signed are first hashed with the hash algorithm specified by the server. 4.2 Server / Client Key Exchange and Key Derivation In the ANNOUNCE message, all data required to set up the encrypted session reside in a EXT_ENC_INFO header extension. This extension contains the server's chosen cipher and hash algorithms along with an ephemeral EC public key to use for the ECDH exchange, a 32 byte random number, its public signing key (RSA or ECDSA), and a signature using this key over the whole UDP packet. Each client then sends in the REGISTER its own random number along with an ephemeral EC public key, using the same EC curve as the server's ECDH key, for the ECDH key exchange. The server and client will then perform an ECDH key derivation, with the result hashed with SHA-256 as a key deriviation function (KDF). This value is the premaster secret. The use of SHA-256 as a KDF differs from TLS 1.3 which uses an identity KDF. This is done to accommodate certain crypto implementations (i.e. Microsoft's CNG) which do not allow the use of an identity KDF when performing an ECDH key exchange. Key derivation between the server and each client is then performed as follows: hs_secret = HKDF-Extract(0, premaster_secret) server_hs_secret = HKDF-Expand-Label(hs_secret, "s hs traffic", hash(Client_HS_Context1), hash_len) client_hs_secret = HKDF-Expand-Label(hs_secret, "c hs traffic", hash(Client_HS_Context1), hash_len) Where "0" is a sequence of hash_len bytes set to 0, "Client_HS_Context1" is: Server_HS_Context + Proxy_HS_Context + client ID + client ECDH key + client random "Proxy_HS_Context" is empty if the session does not involve a proxy, otherwise it is as defined in section 4.4, "Server_HS_Context" is: group ID + group instance ID + server ID + nosig(EXT_ENC_INFO header ext) And "nosig()" signifies setting the signature field to all bytes 0. Signatures are omitted from the message context because multiple copies of a message may be sent, each with different fields in the common header (i.e. message timing) or different payloads (i.e. client / proxy list) resulting in varying signatures. Using the server_hs_secret and client_hs_secret, a key and IV are generated: server_hs_key = HKDF-Expand-Label(server_hs_secret, "key", "", key_length) server_hs_iv = HKDF-Expand-Label(server_hs_secret, "iv", "", iv_length) client_hs_key = HKDF-Expand-Label(client_hs_secret, "key", "", key_length) client_hs_iv = HKDF-Expand-Label(client_hs_secret, "iv", "", iv_length) The client may also send a CLIENT_KEY message along with a REGISTER. This message is required if the server requests authentication of client. This message is encrypted with client_hs_key, with the unencrypted headers passed as additional authenticated data (AAD), and contains the client's RSA or ECDSA signing key along with a signature of the hash of: "UFTP 5, CLIENT_KEY" + Client_HS_Context1 After receiving the REGISTER (and CLIENT_KEY if sent) the server sends a KEYINFO message containing one or more copies of the group master key each encrypted with the server_hs_key for a particular client, along with a 64-bit counter used to generate the IV. This message contains a signature over the hash of: "UFTP 5, KEYINFO" + Server_HS_Context + Proxy_HS_Context + current_message And "current_message" is the the entire UDP packet containing this KEYINFO The additional authenticated data for each encrypted key is: "UFTP 5, group master" + Client_HS_Context2 Where "Client_HS_Context2" is: Client_HS_Context1 + nosig(CLIENT_KEY header) (if sent) The group master key is chosen by the server. It is 32 bytes chosen randomly. The keys derived from this are as follows: app_secret = HKDF-Extract(0, group_master) server_app_secret = HKDF-Expand-Label(app_secret, "s ap traffic", Server_HS_Context, hash_len) clientX_app_secret = HKDF-Expand-Label(app_secret, "c ap traffic", Client_HS_Context2, hash_len) server_app_key = HKDF-Expand-Label(server_app_secret, "key","", key_length) server_app_iv = HKDF-Expand-Label(server_app_secret, "iv","", iv_length) clientX_app_key = HKDF-Expand-Label(clientX_app_secret, "key","",key_length) clientX_app_iv = HKDF-Expand-Label(clientX_app_secret, "iv","", iv_length) Here, server_app_key and server_app_iv are used to encrypt messages from the server to the group, while clientX_app_key and clientX_app_iv are used to encrypt messages from client X back to the server. Upon receiving the KEYINFO message, the client responds with a KEYINFO_ACK message. This message contains a verify_data field that is hash_len bytes long constructed as follows: finished_key = HKDF-Expand-Label(clientX_app_key, "finished", "", hash_len) verify_data = HMAC(finished_key, Hash(Client_HS_Context2 + group_master)) All subsequent messages after a KEYINFO from client X or the server are encrypted using clientX_app_key or server_app_key respectively, and the unencrypted headers are passed as AAD to the AEAD cipher. Each of these messages also contains a 64-bit counter used to generate the IV for that message. The unique ID used to generate the IV should be the same one placed in the Source ID field. Clients receiving a KEYINFO message also uses the unique ID from Source ID. 4.3 Proxy Heartbeats A server proxy may choose to dynamically determine its destination client proxy. It does this by means of authenticated heartbeat messages. The server proxy specifies the public key fingerprint of the client proxy it wishes to send to. This is useful when the client proxy is NATed and its IP address cannot be determined ahead of time, and may in fact change on the fly. When a server proxy in this mode receives an HB_REQ message, it responds with an HB_RESP message containing a flag indicating that authentication is required along with a randomly chosen nonce value. The client proxy is then expected to sign the nonce with its public key and sends back the nonce, the signed nonce, and its public key in another HB_REQ message. When the server proxy receives this message, it first checks the plaintext nonce to see if it matches the last nonce it sent out. If so, it verifies the client proxy's public key fingerprint then verifies the signature. If these checks all pass, the server uses the incoming address of the HB_REQ as its downstream address, and sends back an HB_RESP indicating successful authentication. At this time the server will randomly select a new nonce so the old one is not reused. If any of the checks fail, the server proxy sends back an HB_RESP message indicating failed authentication, and the current destination remains unchanged. Any future HB_REQ messages the server proxy gets from the established downstream client proxy is automatically accepted. Only when the IP/port does not match will the server proxy issue a challenge. 4.4 Proxy Key Exchange When proxies are in use, the client proxy or response proxy sits between the server and clients for the purposes of setting up the encrypted channel. The proxy acts as a client when exchanges messages with the server, and acts partially as the server when exchanging messages with clients. So the server is exchanging keys with and authenticating the proxy instead of the clients, while the clients are exchanging keys with and authenticating both the proxy and the server. There is additional context called "Proxy_HS_Context" which is defined as: proxy ID + nosig(PROXY_KEY header) When a proxy is exchanging keys with a server, it acts as a client and so Proxy_HS_Context is empty when exchanging keys with the server. It is only used as part of the key exchange between a proxy and a client. Note also that Server_HS_Context is still used by clients to do key derivation from the group master so that clients can decrypt messages coming directly from the server without the proxy needing to modify them. A client proxy or response proxy will send a PROXY_KEY message after receiving an ANNOUNCE (which a client proxy will first forward). This message contains its own ECDH key and signing key. It also contains a signature over: "UFTP 5, PROXY_KEY" + Server_HS_Context + Proxy_HS_Context When a client configured to send to a proxy receives the ANNOUNCE, it waits for a PROXY_KEY message and uses the proxy's ECDH key to derive the premaster secret. When the server expects client authentication, the proxy will respond directly to the server with a CLIENT_KEY, using the shared key it established with the server to encrypt it. Similarly, clients send a CLIENT_KEY to the proxy encrypted using the shared it established with the proxy, and the proxy does not forward this message. When the server sends a KEYINFO, the proxy will respond to it directly with a KEYINFO_ACK. The server then responds with a REG_CONF listing the clients the proxy registered with the server, after which the proxy will generate a new KEYINFO message to those clients. 5. Messages 5.1 Message Flow While it would save one round trip to send a KEYINFO and FILEINFO together with encryption enabled and only one file to send, keeping them separate prevents eavesdroppers from determining information about the encrypted stream, such as the number of files being sent. See section 3.2 for more details. 5.1.1 Announce/Register phase with encryption: 5.1.1.1 Without proxies Server Client ------ ------ ANNOUNCE ---> <--- REGISTER <--- CLIENT_KEY (optional) KEYINFO ---> <--- KEYINFO_ACK 5.1.1.2 With server/client proxies Server Server Proxy Client Proxy Client ------ ------------ ------------ ------ ANNOUNCE ---> ---> ---> PROXY_KEY ---> <--- REGISTER <--- CLIENT_KEY (optional) <--- <--- REGISTER <--- <--- CLIENT_KEY (optional) KEYINFO ---> ---> <--- <--- KEYINFO_ACK REG_CONF ---> ---> KEYINFO ---> <--- KEYINFO_ACK 5.1.1.3 With response proxy Server Response Proxy Client ------ -------------- ------ ANNOUNCE ---> ------------------------> PROXY_KEY ---> <--- REGISTER <--- CLIENT_KEY (optional) <--- REGISTER <--- CLIENT_KEY (optional) KEYINFO ---> <--- KEYINFO_ACK REG_CONF ---> KEYINFO ---> <--- KEYINFO_ACK 5.1.2 Announce/Register phase without encryption 5.1.2.1 Without proxies Server Client ------ ------ ANNOUNCE ---> <--- REGISTER REG_CONF ---> 5.1.2.2 With server/client proxies Server Server Proxy Client Proxy Client ------ ------------ ------------ ------ ANNOUNCE ---> ---> ---> <--- REGISTER <--- <--- REGISTER REG_CONF ---> ---> ---> 5.1.2.3 With response proxy Server Response Proxy Client ------ -------------- ------ ANNOUNCE ---> ------------------------> <--- REGISTER <--- REGISTER REG_CONF ---> ------------------------> 5.1.3 File Transfer phase: Server Client ------ ------ FILEINFO ---> (either) <--- FILEINFO_ACK (or) <--- COMPLETE FILESEG ---> ... CONG_CTRL ---> <--- CC_ACK ... DONE ---> (either) <--- STATUS (or) <--- COMPLETE ... 5.1.4 Completion/Confirmation phase: Server Client ------ ------ DONE ---> <--- COMPLETE DONE_CONF ---> 5.2 Message Details All messages start with the UFTP header, followed by a message specific header. With the exception of an ENCRYPTED message, each message header starts with an 8 bit function number. This allows for determining the message type of a decrypted message, so the message type is not revealed in the UFTP header. Messages may contain optional header extensions. Some are defined here, although others may be added without breaking backward compatibility. Any unexpected header extension should be ignored. 5.2.1 UFTP header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UFTP ID | Function | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Inst. | GRTT | Group Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UFTP ID: 8 bits Defines the version number of the protocol. Currently 0x50. Function: 8 bits The message number of the contained message. If the message is encrypted, this always specifies the message number for ENCRYPTED. Sequence Number: 16 bits A monotonically increasing sequence number used for congestion control and replay attack prevention purposes. Source ID: 32 bits The unique ID of the sender. Group ID: 32 bits A unique identifier for the current session. Group Instance: 8 bits A sequence number that increases each time the session identified by the Group ID is retried. This allows for differentiating retried instances of the same session. GRTT: 8 bits For messages originating from a server, a quantized version of the current Group Round Trip Time. See RFC 5401 section 3.7.4 for details of how this field is encoded. Group Size: 8 bits For messages originating from a server, a quantized version of the total number of clients in the current session. This field consists of a 5 bit mantissa and a 3 bit exponent. The mantissa is scaled so that a value of 0.0 is represented as 0 and a value of 10.0 is represented as 32. Reserved: 8 bits Reserved for future use and should be set to 0. 5.2.2 ENCRYPTED 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV Counter (high bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV Counter (low bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Specifies an encrypted message. Contains a signature followed by the encrypted message payload (which is one of the messages below). The signature is either an HMAC using the group key or an RSA/ECDSA signature using the sender's RSA/ECDSA key over the whole UFTP message, depending on the signature type chosen by the server. Alternately, if an authenticated cipher was chosen, the signature field will be empty since the signature is embedded in the encrypted data. IV Counter: 64 bits A monotonically increasing counter used as part of the symmetric key IV for the encrypted payload. This field should be implemented as two 32-bits fields for purposes of alignment. Reserved: 16 bits MUST be set to 0 Payload length: 16 bits The length of the encrypted payload in bytes (must be a multiple of 4). Encrypted Payload: varies The encrypted message, encrypted with the group symmetric key. 5.2.3 ANNOUNCE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Flags | Robust Factor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC Type | Reserved | Block Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Multicast Address | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Private Multicast Address | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client ID | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the server to initiate a file transfer. Contains basic info needed by clients to initiate a session. For closed group membership, the list of allowed clients is specified in the body. Multiple messages may be sent to accommodate the full list of clients. This message goes over the public multicast address. All subsequent server messages go over the private multicast address. If the server needs to resend this message under closed group membership, only clients that did not respond are listed. Function: 8 bits The message number for this message. Always 1. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Flags: 8 bits 0x01 - SYNC_MODE If set, this indicates that the session is operating in sync mode. Files received by clients are checked against existing files to see whether or not the file should be accepted. 0x02 - SYNC_PREVIEW Indicates sync preview mode for the session. This is like sync mode, except client don't actually receive any files. 0x04 - IPV6 Indicates that the public multicast address and private multicast address are IPv6 addresses when set. All other bits should be set to 0. Robust: 8 bits Sets the robustness factor for the session. This value dictates how many times certain messages may be retransmitted. CC Type: 8 bits Specifies the congestion control algorithm in use. See section 5.3 for a list of valid values. Reserved: 8 bits Reserved for future use and should be set to 0. Block Size: 16 bits The size of the body for UFTP messages. This value should be somewhat less that the path MTU to allow room for any UFTP header or extension as well as the UDP and IP headers and extensions. Timestamp_microseconds: 64 bits The current time expressed as microseconds since the UNIX epoch of 1/1/1970 00:00:00 UTC. Public Multicast Address: varies The public multicast address used by this session. May be an IPv4 address of 4 bytes or an IPv6 address of 16 bytes. Private Multicast Address: varies The private multicast address used by this session. May be an IPv4 address of 4 bytes or an IPv6 address of 16 bytes. The public and private addresses must be the same IP version. Header Extensions: varies Contains any header extensions that may be present Client ID: 32 bits each The body of the message. Contains the unique ID of one or more clients that are allowed to join under closed group membership. 5.2.3.1 EXT_ENC_INFO 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Extension | Flags | Reserved | | Type | Length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Type | Hash Type | Signature Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECDH Key Length | Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | + + | Server Random Number | + + | | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Blob | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ECDH Key Blob | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Public Key Signature | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ A header extension appended to an ANNOUNCE message indicating encryption parameters for the session. Extension Type: 8 bits The extension number for this extension. Always 1. Extension Length: 8 bits The total length of the extension in 4 byte words. Flags: 8 bits 0x01 - CLIENT_AUTH Specifies that the client should send a CLIENT_KEY message in addition to a REGISTER when responding when set. All other bits should be set to 0. Reserved: 8 bits MUST be set to 0. Key Type: 8 bits Specifies the key type number of the symmetric encryption algorithm to use. See section 5.3 for the list of valid values. Hash Type: 8 bits Specifies the hash type number of the hashing algorithm to use for key derivation. See section 5.3 for the list of valid values. Signature Key Length: 16 bits The length in bytes of the server's public signature key blob. ECDH Key Length: 16 bits The length in bytes of the server's ephemeral ECDH public key blob. Signature Length: 16 bits The length in bytes of the server's public key signature. Server Random Number: 256 bits A 32-byte random number chosen by the server used to derive the master secret key between the server and each client. Public Key Blob: varies A key blob containing the server's RSA or ECDSA public signature key. ECDH Key Blob: varies A key blob containing the server's ephemeral ECDH public key. Public Key Signature: varies The signature for this message. It applies to the entire UFTP packet, including the UFTP header. Signed using the sender's RSA/ECDSA private key. 5.2.3.2 RSA key blob 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Blob Type | Reserved | Modulus Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Exponent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Modulus | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A keyblob containing an RSA public key Blob Type: 8 bits Specifies the keyblob type. Always 1. Reserved: 8 bits MUST be set to 0. Modulus Length: 16 bits The length in bytes of the RSA public key modulus Public Key Exponent: 32 bits The public key exponent of the RSA public key. Public Key Modulus: varies The public key modulus of the RSA public key. 5.2.3.3 EC key blob 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Blob Type | Curve | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EC Public Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A keyblob containing an Elliptic Curve public key, which may be used for either ECDH or ECDSA. Blob Type: 8 bits Specifies the keyblob type. Always 2. Curve: 8 bits Specifies the named curve used by this public key. See section 5.3 for the list of valid values. Key Length: 16 bits The Length in bytes of the the EC public key. EC Public Key: varies The EC public key value, specified as the X coordinate followed by the Y coordinate. 5.2.4 REGISTER 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | ECDH Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | + + | Client Random Number | + + | | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECDH key blob | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client ID | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the client to acknowledge receipt of an ANNOUNCE. If encryption is requested, also contains a random number and an ephemeral ECDH public key Function: 8 bits The message number for this message. Always 2. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. ECDH key Length: 16 bits The length in bytes of the client's ephemeral ECDH public key blob. Timestamp_microseconds: 64 bits The last server timestamp sent, adjusted for the time between receiving the last server message and sending this message. Client Random Number: 256 bits A 32-byte random number chosen by the client used to derive the premaster secret key between the server and each client. ECDH Key Blob: varies A key blob containing the client's ephemeral ECDH public key. Client ID: 32 bits each The body of the message. Contains the unique ID of one or more clients that a proxy received a REGSITER from and is now relaying to the server. 5.2.5 CLIENT_KEY 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Length | Signed Verify Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Blob | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Signed Verify Data | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Sent by the client if the server requests client authentication. This message is always encrypted and embedded within an ENCRYPTED message. Function: 8 bits The message number for this message. Always 3. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Reserved: 16 bits Reserved for future use and should be set to 0. Public Key Length: 16 bits The length in bytes of the client's public signature key blob. Signed Verify Data Length: 16 bits The length in bytes of the signed verify data field. Public Key Blob: varies A keyblob containing client's public signing key. Signed Verify Data: varies The signature from the client's private signature key of verification data based on the hash of the cryptographic parameters exchanged to this point. 5.2.6 REG_CONF 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Reserved | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client ID | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the server in response to a REGISTER if there is no encryption. Contains a list of clients that the server received a REGISTER for, and multiple messages may be sent to accommodate the full list of clients. Also sent if the REGISTER came from a proxy. This allows proxies to confirm registrations when encryption is enabled. The server will not resend this message for a given client unless it receives an extra REGSITER from that client. Function: 8 bits The message number for this message. Always 4. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Reserved: 16 bits Reserved for future use and should be set to 0. Client ID: 32 bits each The body of the message. Contains the unique ID of one or more clients that the server received a REGISTER for. 5.2.7 KEYINFO 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV Counter (high bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV Counter (low bits) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Public Key Signature | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ encrypted | Client ID | key 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | + + | | + + | | + + | Encrypted Group Master | + + | | + + | | + + | | + + | | + + | | + + | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ encrypted | Client ID | key 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the server in response to a REGISTER if encryption is enabled. Contains the list of clients that the server received a REGISTER for, and multiple message may be sent to accommodate the full list of clients. If the server needs to resend this message, only clients that did not respond are listed. Also, for each listed client, it contains the group master key encrypted with the master secret key negotiated with that client. If a REGISTER is received from a proxy, KEYINFO gets sent directly to the proxy, not the clients it serves. Function: 8 bits The message number for this message. Always 5. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Signature Length: 16 bits The length in bytes of the server's public key signature. IV Counter: 64 bits A monotonically increasing counter used as part of the symmetric key IV for the encrypted group master key for each listed client. This field should be implemented as two 32-bits fields for purposes of alignment. Public Key Signature: varies The signature over the handshake messages up to this point. Signed using the sender's RSA/ECDSA private key. The message body contains a list of the following pair of fields: Client ID: 32 bits each The unique ID of a client that the server received a REGISTER for. Encrypted Group Master: 384 bits each The encrypted group master plus AEAD verify data, encrypted using the master symmetric key for the associated client. 5.2.8 KEYINFO_ACK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Verify Data Length | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Verify Data | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the client in response to a KEYINFO. Contains verification data based on the hash of the cryptographic parameters exchanged to this point. This message is always encrypted and embedded within an ENCRYPTED message. Function: 8 bits The message number for this message. Always 6. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Verify Data Length: 16 bits The length in bytes of the Verify Data field. Verify Data: varies Contains a hash of all cryptographic parameters exchanged for the session 5.2.9 FILEINFO 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | File ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Type | Reserved | File Timestamp (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name Length | Link Length | File Size (high bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Size (low bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Timestamp (low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | File Name | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Link Name | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client ID | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the server to give information on a particular file being sent. Contains the list of currently active clients, and multiple message may be sent to accommodate the full list of clients. If the server needs to resend this message, only clients that did not respond are listed. If encryption is enabled, this message is encrypted and embedded within an ENCRYPTED message. Function: 8 bits The message number for this message. Always 7. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. File ID: 16 bits The identifier of the current file. Chosen by the server sequentially starting at 1. File Type: 8 bits Specifies the type of file being sent (regular file, directory, symbolic link, delete request, or free dist space request). See section 5.3 for the list of valid values. Reserved: 8 bits Reserved for future use and should be set to 0. File Timestamp (high): 16 bits The high order 16 bits of the file's timestamp as seconds since the UNIX epoch of 1/1/1970 00:00:00 UTC. Name Length: 8 bits The length of the file name in 4 byte words. If the file name is not a multiple of 4, this field is null padded at the end. Link Length: 8 bits The length of the link name in 4 byte words. If the link name is not a multiple of 4, this field is null padded at the end. May be 0. File Size: 48 bits The size of the file to send in bytes. File Timestamp (low): 32 bits The low order 32 bits of the file's timestamp as seconds since the UNIX epoch of 1/1/1970 00:00:00 UTC. Timestamp_microseconds: 64 bits The current time expressed as microseconds since the UNIX epoch of 1/1/1970 00:00:00 UTC. This field is used in round trip time measurements. File Name: varies The path name of the file to send. A slash (/) is used as a directory separator. The file gets created with this path in the client's destination directory. Link Name: varies If the File Type field specifies that the file is a symbolic link, this field specifies the link destination. Client ID: 32 bits each The body of the message. Contains the ID of one or more active clients. 5.2.10 FILEINFO_ACK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | File ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (low) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client ID | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the client in response to a FILEINFO. Contains the file ID . If encryption is enabled, this message is encrypted and embedded within an ENCRYPTED message. Function: 8 bits The message number for this message. Always 8. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. File ID: 16 bits The identifier of the current file. Flags: 8 bits 0x01 - PARTIAL If set, this indicates that the client partially received the indicated file on a prior run. Valid only in response to a FILEINFO. All other bits should be set to 0. Reserved: 24 bits Reserved for future use and should be set to 0. Timestamp_microseconds: 64 bits The last server timestamp sent, adjusted for the time between receiving the last server message and sending this message. Client ID: 32 bits each The body of the message. Contains the unique ID of one or more clients that a proxy received a FILEINFO from and is now relaying to the server. 5.2.11 FILESEG 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | File ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Section | Block Number in Section | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the server, and contains a block of data following this header. If encryption is enabled, this message is encrypted and embedded within an ENCRYPTED message. Function: 8 bits The message number for this message. Always 9. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. File ID: 16 bits The identifier of the current file. Section: 16 bits The section number for this block. Block Number in Section: 16 bits The number of this block within the current section. Data: varies The body of the message. Contains a block of the current file. 5.2.11.1 EXT_TFMCC_DATA_INFO 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Extension | Send Rate | | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC Sequence | CC Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This extension, added to a FILESEG message, contains information necessary to support TFMCC. Extension Type: 8 bits The extension number for this extension. Always 2. Extension Length: 8 bits The total length of the extension in 4 byte words. Send Rate: 16 bits The current transmission rate of the server. CC Sequence: 16 bits A sequence number which increases by 1 at the start of a new feedback round. CC Rate: 16 bits The current congestion control suppression rate. Only clients with a rate less than this may send congestion control feedback in a CC_ACK message. 5.2.12 DONE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | File ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Section | Reserved | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client ID | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the server at the end of a section to request NAKs. Contains the list of clients that the server needs status for, and multiple message may be sent to accommodate the full list of clients. If the server needs to resend this message, only clients that did not respond are listed. If encryption is enabled, this message is encrypted and embedded within an ENCRYPTED message. Function: 8 bits The message number for this message. Always 10. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. File ID: 16 bits The identifier of the current file. If zero, indicates the beginning of the Completion/Confirmation phase to end the session. Section: 16 bits The section number the server is requesting status for. Reserved: 16 bits Reserved for future use and should be set to 0. Client ID: 32 bits each The body of the message. Contains the ID of one or more clients the server needs status for. 5.2.13 STATUS 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | File ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Section | Reserved | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NAK Content | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the client either in response to a DONE message or at the end of a section if loss is detected. If encryption is enabled, this message is encrypted and embedded within an ENCRYPTED message. Function: 8 bits The message number for this message. Always 11. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. File ID: 16 bits The identifier of the current file. Section: 16 bits The section number this STATUS is requesting retransmissions for. Reserved: 16 bits Reserved for future use and should be set to 0. NAK Contest: varies The body of the message. Contains a bitmap of the blocks in the section, where a set bit designates a NAK for the given block. 5.2.13.1 EXT_TFMCC_ACK_INFO 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Extension | Flags | Reserved | | Type | Length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC Sequence | CC Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This extension, added to a STATUS or CC_ACK message, contains information necessary to support TFMCC. Extension Type: 8 bits The extension number for this extension. Always 3. Extension Length: 8 bits The total length of the extension in 4 byte words. Flags: 8 bits 0x01 - CC_CLR If set, specifies this client is the CLR. Not currently used. 0x02 - CC_RTT If set, specifies that the client has received an RTT measurement from the server. 0x04 - CC_START If set, specifies that the client is in slow start mode. 0x08 - CC_LEAVE If set, specifies that the client is preparing to leave the session. All other bits should be set to 0. Reserved: 8 bits Reserved for future use and should be set to 0. CC Sequence: 16 bits The most recent CC sequence number received from the server. CC Rate: 16 bits The client's congestion control rate. If CC_START is set, Client ID: The ID of the client that created this extension. When a proxy forwards or aggregates client responses, this allow the server to know who this extension belongs to. Timestamp_microseconds: 64 bits The last server timestamp sent, adjusted for the time between receiving the last server message and sending this message. 5.2.14 COMPLETE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | File ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client ID | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by the client in response to a DONE message when the client has received the whole file. May also be sent in a response to a FILEINFO if the session is a restart session and the client received the whole file on a prior attempt. If encryption is enabled, this message is encrypted and embedded within an ENCRYPTED message. If the file ID is 0, indicating the end of the session, all files and directories sent during the session are moved from the client's temp directory to the destination directory, if a temp directory was specified. Files within directories are moved as part of the containing directory. Function: 8 bits The message number for this message. Always 12. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. File ID: 16 bits The identifier of the current file. Status: 8 bits Specifies the status of the COMPLETE message. When in sync mode, a status of COMP_STAT_NORMAL specifies that the file was a new file copied over, a status of COMP_STAT_SKIPPED specifies that the file was skipped because the incoming file was older, and a status of COMP_STAT_OVERWRITE specifies that the file overwrote an existing file. When not in sync mode, the status is set to COMP_STAT_NORMAL if the file was sent successfully. If the client rejects the file due to a pathname or filename issue, regardless of sync mode, the status is set to COMP_STAT_REJECTED. Reserved: 24 bits Reserved for future use and should be set to 0. Client ID: 32 bits each The body of the message. Contains the ID of one or more clients that a proxy received a COMPLETE from and is now relaying to the server. 5.2.14.1 EXT_FREESPACE_INFO 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension | Extension | Reserved | | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Free Space (high bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Free Space (low bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This extension, added to a COMPLETE message, contains the amount of free disk space in bytes in the client's primary destination directory. Extension Type: 8 bits The extension number for this extension. Always 7. Extension Length: 8 bits The total length of the extension in 4 byte words. Reserved: 16 bits Reserved for future use and should be set to 0. Free Space: 64 bits The amount of free disk space in bytes. 5.2.15 DONE_CONF 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Reserved | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Client IP Address | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Send by the server in response to a COMPLETE message at the end of a session. Contains the list of clients that have completed. Multiple messages may be sent to accommodate the full list of clients. The server will not resend this message for a given client unless it receives an extra COMPLETE from that client. If encryption is enabled, this message is encrypted and embedded within an ENCRYPTED message. Function: 8 bits The message number for this message. Always 13. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Reserved: 16 bits Reserved for future use and should be set to 0. Client ID: 32 bits each The body of the message. Contains the ID of one or more clients that a server received a COMPLETE from. 5.2.16 ABORT 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Sent by either a client or server when an error condition occurs. This message may or may not be encrypted, depending on whether or not the group master key has been negotiated. Function: 8 bits The message number for this message. Always 19. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Flags: 8 bits 0x01 - CURRENT_FILE Applies only if sent to a client, and only if the Host field is zero. If set, specifies that all clients not actively working on the current file must abort. Clients that finished the current file do NOT abort and may receive the next file in the session. All other bits should be set to 0. Reserved: 8 bits Reserved for future use and should be set to 0. Host: 32 bits If sent by the server, specifies the client the server wishes to abort, or zero to specify that all clients must abort. If sent by a client, this is set to zero. If sent by a proxy on behalf of a client, it is set to the IP of the client that is aborting. If sent by a proxy on its own behalf, it is set to zero. Message: 300 bytes Descriptive text stating the reason for the abort. 5.2.17 HB_REQ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Length | Signed Nonce Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Blob | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signed Nonce | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Sent by a proxy (usually a client proxy) to an upstream proxy for the purpose of opening up a hole in a firewall that the upstream proxy can send through, and revealing the proxy's NATed IP to the upstream proxy so the upstream proxy knows where to send other requests. Function: 8 bits The message number for this message. Always 14. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Reserved: 16 bits Reserved for future use and should be set to 0. Public Key Length: 16 bits The length in bytes of the proxy's public key blob. Signed Nonce Length: 16 bits The length in bytes of the signed nonce field. Nonce: 32 bits The value received from a previous HB_RESP that is to be signed. Public Key Blob: varies A keyblob containing the proxy's RSA or ECDSA public key. Signed Nonce: varies The signature from the proxy's RSA/ECDSA private key of the specified nonce. 5.2.18 HB_RESP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Authenticated | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Sent by a proxy in response to an HB_REQ message. Function: 8 bits The message number for this message. Always 15. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Authenticated: 8 bits Specifies the status of the HB_REQ this message is responding to. A value of HB_AUTH_OK means authentication succeeded or was not required. A value of HB_AUTH_CHALLENGE means expected authentication info was not specified. A value of HB_AUTH_FAILED means the given authentication info was invalid. Reserved: 8 bits Reserved for future use and should be set to 0. Nonce: 32 bits When Authenticated = HB_AUTH_CHALLENGE, the nonce value that is expected to be signed in an authenticated HB_REQ. 5.2.19 PROXY_KEY 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Public Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECDH Key Length | Signature Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key Blob | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ECDH Key Blob | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Signature | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Sent by a response proxy to clients for the purpose supplying its public RSA/ECDSA key and public ECDH key. When a client gets an ANNOUNCE directly from a server, it contains the server's RSA/ECDSA public key and ECDH key. The client can then use the proxy's keys to perform the key exchange instead of the server's key. Function: 8 bits The message number for this message. Always 17. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Public Key Length: 16 bits The length in bytes of the proxy's public key blob. ECDH Key Length: 16 bits The length in bytes of the proxy's public ECDH key blob. Signature Length: 16 bits The length in bytes of the signature nonce field. Public Key Blob: varies A keyblob containing the proxy's RSA or ECDSA public key. ECDH Key Blob: varies A keyblob containing the proxy's ephemeral ECDH public key. Signature: varies The signature over the this message and the server's key exchange 5.2.20 CONG_CTRL 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC Sequence | CC Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp_microseconds (low) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | CC Item | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sent by a server as part of congestion control and round trip time calculations. This message supplies clients with an up to date timestamp to adjust and respond to for round trip time as well as a list of round trip times for one or more clients. Function: 8 bits The message number for this message. Always 20. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Reserved: 16 bits Reserved for future use and should be set to 0. CC Sequence: 16 bits A sequence number which increases by 1 at the start of a new feedback round. CC Rate: 16 bits The current congestion control suppression rate. Only clients with a rate less than this may send congestion control feedback in a CC_ACK message. Timestamp_microseconds: 64 bits The current time expressed as microseconds since the UNIX epoch of 1/1/1970 00:00:00 UTC. CC Item: 64 bits each The body of the message. Contains a list of congestion control data items. Defined as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | RTT | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Client ID: 32 bits The unique ID of the client this item represents. Flags: 8 bits 0x01 - CC_CLR If set, specifies this client is the CLR. 0x02 - CC_RTT If set, specifies that the server calculated the RTT to this client. 0x04 - CC_START If set, specifies that the server is in slow start mode. 0x08 - CC_LEAVE If set, specifies that the client is preparing to leave the session. Not currently used in this message. All other bits should be set to 0. RTT: 8 bits The round trip time to this client as calculated by the server. Reserved: 16 bits Reserved for future use and should be set to 0. 5.2.21 CC_ACK 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Header Length | Reserved | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Header Extensions (if applicable) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ This message contains a congestion control feedback response from a client. There should normally be at least one header extension present such as EXT_TFMCC_ACK_INFO to supply the specific congestion control data for a particular scheme. Function: 8 bits The message number for this message. Always 21. Header Length: 8 bits The total length of the header, including extensions, in 4 byte words. Reserved: 16 bits Reserved for future use and should be set to 0. 5.3 Message Constants 5.3.1 Message type numbers ANNOUNCE 1 REGISTER 2 CLIENT_KEY 3 REG_CONF 4 KEYINFO 5 KEYINFO_ACK 6 FILEINFO 7 FILEINFO_ACK 8 FILESEG 9 DONE 10 STATUS 11 COMPLETE 12 DONE_CONF 13 HB_REQ 14 HB_RESP 15 (reserved) 16 PROXY_KEY 17 ENCRYPTED 18 ABORT 19 CONG_CTRL 20 CC_ACK 21 5.3.2 Key type numbers None 0 (reserved) 1..4 AES 128 GCM 5 AES 256 GCM 6 AES 128 CCM 7 AES 256 CCM 8 5.3.3 Hash type numbers None 0 (reserved) 1..2 SHA-256 3 SHA-384 4 SHA-512 5 5.3.4 Key Blob type numbers None 0 RSA 1 EC 2 5.3.5 Heartbeat authentication codes HB_AUTH_FAILED 0 HB_AUTH_OK 1 HB_AUTH_CHALLENGE 2 5.3.6 File types Regular file 0 Directory 1 Symbolic Link 2 Delete file 3 Get free space 4 5.3.7 Completion status COMP_STAT_NORMAL 0 COMP_STAT_SKIPPED 1 COMP_STAT_OVERWRITE 2 COMP_STAT_REJECTED 3 5.3.8 Extension types EXT_ENC_INFO 1 EXT_TFMCC_DATA_INFO 2 EXT_TFMCC_ACK_INFO 3 EXT_PGMCC_DATA_INFO 4 EXT_PGMCC_NAK_INFO 5 EXT_PGMCC_ACK_INFO 6 EXT_FREESPACE_INFO 7 5.3.9 Congestion control types CC_NONE 0 CC_UFTP3 1 CC_TFMCC 2 CC_PGMCC 3 5.3.12 Elliptic Curve named curves (reserved) 1..22 secp256r1 23 // also prime256v1 secp384r1 24 secp521r1 25