-
Notifications
You must be signed in to change notification settings - Fork 0
/
protocol.txt
executable file
·2031 lines (1588 loc) · 87.1 KB
/
protocol.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
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 4 * GRTT with
a maximum time of 4 * 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) will be 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
The encryption protocol borrows from TLS (RFC5246) and DTLS (RFC4347). 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.
Valid block encryption algorithms are DES and 3 key Triple DES in CBC mode,
and AES-128 and AES-256 in either CBC, GCM or CCM mode. While AES is more
secure and therefore preferred, DES and Triple DES are supported for
environments where AES is not available. GCM and CCM modes are for
authenticated encryption, so a separate signature is not required.
For the block encryption algorithm chosen, there are:
encryption_key_length
IV_length
For each message to be encrypted, an IV must be generated as follows:
For a 128-bit IV (for AES in CBC mode):
IV = S + UID + CTR
For a 96-bit IV (for AES in GCM or CCM mode):
IV = (S XOR UID) + CTR
For a 64-bit IV (for DES or 3 key Triple DES):
IV = (S + UID) XOR CTR
where CTR is a monotonically increasing 64-bit counter, UID is the unique ID
of the message sender, and S is a 32-bit salt, derived below.
Valid hash algorithms are SHA-1, SHA-256, SHA-384, and SHA-512. While SHA-256
or more is preferred, SHA-1 is supported for environments where SHA-256 is
not available.
For the hash algorithm chosen, there is:
hash_length
The server has the option to use a symmetric key HMAC, an asymmetric key
signature (RSA or ECDSA), or a cipher in GCM or CCM mode for authentication of
encrypted messages. Using a GCM or CCM cipher allows encryption and signature
generation to be done in a single step and is fastest (particularly GCM).
HMAC is slower that GCM/CCM but faster than asymmetric keys. While asymmetric
key signatures are larger and slower, they do protect against attacks
from within the group. When using asymmetric key signatures, all clients
MUST use a key of the same type and size (for RSA) or curve (for ECDSA) as
the server. Clients may maintain multiple private keys of differing types
and sizes to accommodate different servers.
During the initial setup, there is an exchange of symmetric keys between the
server and each client. This can be done with either RSA encryption or with
an Elliptic Curve Diffie-Hellman (ECDH) key exchange. With ECDH, the key
exchange parameters are validated with either RSA signatures or Elliptic Curve
DSA (ECDSA) signatures.
In the ANNOUNCE message, the server sends a random number along with certain
key exchange keys. The random number is 32 bytes, with the first 4 being the
current time in the standard UNIX time format, and the remaining 28 generated
by a secure random number generator. If RSA is chosen for key exchange, the
ANNOUNCE includes the server's public RSA key. If ECDH is chosen for key
exchange, it contains an ephemeral EC public key to use for the ECDH exchange
along with either its RSA public key or its ECDSA public key, plus a signature
over the whole UDP packet using the RSA/ECDSA key.
Each client then sends in the REGISTER its own random number, constructed
identically to the server's, along with it's part of the key exchange. In the
case of RSA key exchange, it includes a 48 byte premaster secret key encrypted
with the server's public key. The premaster secret consists of 1 byte for the
client's version and the remaining 47 chosen by a secure random number
generator. In the case of an ECDH key exchange, it includes 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-1, and the resulting value becomes the
premaster secret.
The client may also send a CLIENT_KEY message along with a REGISTER. This
message is required if the server requests either RSA/ECDSA signatures or
simply to authenticate the client. This messages also contains a signature
(using the client's RSA or ECDSA key) of the hash of:
group ID + private address + server random + client random + premaster secret
The server and each client calculates a 48 byte master secret as follows:
master_secret = PRF(pre_master_secret, "master secret",
server_random + client_random)[0-47]
When SHA-1 is the selected hash, the pseudo-random function (PRF) is as defined
in TLS 1.1 (RFC4346) which uses a SHA1/MD5 combination. Otherwise, the
pseudo-random function (PRF) is as defined in TLS 1.2 (RFC5246) using the
server selected hash function.
Using the master secret, a key block is generated:
key_block = PRF(master_secret, "key expansion",
server_random +
client_random);
From the key block, the first hash_length bytes comprise the HMAC key,
the next encryption_key_length bytes comprise the session key, and the
next 4 bytes comprise the salt from which session IVs are derived.
Currently, the HMAC key based on the master secret between the server and a
particular client is not used, but the key material is generated anyway to be
consistent with key expansion of the group key and as a hedge in case it could
be used in a future release.
After receiving the REGISTER the server sends a KEYINFO message containing
the group master key encrypted with the session key for the client, along with
a 64-bit counter used to generate the IV. If an authenticated cipher mode was
chosen (GCM/CCM), the encryption is instead performed in CBC mode as a
signature is not required at this stage. A KEYINFO can contain the group key
encrypted multiple times, with each one encrypted with a different client's
session key and grouped with the unique ID of the client. The group master key
is chosen by the server. It is 48 bytes, with the first byte being the server
version and the remaining 47 bytes chosen by a secure random number generator.
To save bandwidth, only the 47 random bytes are encrypted. Given the block
size of the supported cyphers of 8 or 16, this results in the encrypted key
being 48 bytes (instead of 64, if 48 bytes were encrypted). The other byte
can be derived from the version of the KEYINFO message.
From the group master key, a key block is generated as follows:
key_block = PRF(group_master, "key expansion", server_random);
From the key block, the first hash_length bytes comprise the group HMAC key,
the next encryption_key_length bytes comprise the group session key, and the
next 4 bytes comprise the salt from which group session IVs are
derived.
Upon receiving the KEYINFO message, the client responds with an KEYINFO_ACK
message. This message contains a 12 byte verify_data field constructed as
follows:
PRF(group_master, "client finished", Hash(handshake_values))[0-11]
Where Hash is the server selected hash function and handshake_values is:
group ID + private address + server random + client random +
premaster secret + [ client_key_blob ] + group_master
where client_key_blob is an exported keyblob of the client's public key, if
a CLIENT_KEY message was sent. See section 5 for details of this keyblob.
All subsequent messages after a KEYINFO from either client or server are
encrypted using the group session key, and the whole UDP packet is signed with
either the group HMAC key, the sender's RSA/ECDSA key, or the GCM/CCM mode
cipher, depending on what the server selects. 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.
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.
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 ---> ---> --->
<--- 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 --->
------------------------>
<--- 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 0x30.
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 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature length | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Signature length: 16 bits
The length of the signature in bytes (must be a multiple of 4).
Payload length: 16 bits
The length of the encrypted payload in bytes (must be a multiple of 4).
Signature: varies
The signature for this message. It applies to the entire UFTP packet,
including the UFTP header. May be either an HMAC using the group hmac
key or an RSA/ECDSA signature using the sender's RSA/ECDSA private key.
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_seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp_microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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_seconds: 32 bits
The current time expressed as seconds since the UNIX epoch of
1/1/1970 00:00:00 UTC.
Timestamp_microseconds: 32 bits
The microsecond portion of the current time. This field and the above
field are used in round trip time measurements.
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 | Keyex | Sig |
| Type | Length | | Type | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Type | Hash Type | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Key Length | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| |
+ +
| Server Random Number |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key Blob |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Diffie-Hellman 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.
Key Exchange Type: 4 bits
Specifies the key exchange algorithm to use. See section 5.3 for the
list of valid values.
Signature Type: 4 bits
Specifies the signature type number of the signature to use on encrypted
messages. See section 5.3 for the list of valid values.
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 HMAC
signatures and key derivation. See section 5.3 for the list of valid
values.
Public Key Length: 16 bits
The length in bytes of the server's public key blob.
Diffie-Hellman Key Length: 16 bits
The length in bytes of the server's Diffie-Hellman key blob. Must be 0
if the key exchange algorithm is RSA.
Signature Length: 16 bits
The length in bytes of the server's public key signature. Must be 0
if the key exchange algorithm is RSA.
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 key.
Diffie-Hellman 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 | Key Info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp_seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp_microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| |
+ +
| Client Random Number |
+ +
| |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Info |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 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 a premaster secret key encrypted
with the server's public RSA 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.
Key Info Length: 16 bits
The length in bytes of the key info field.
Timestamp_seconds: 32 bits
The seconds part of the last server timestamp sent, adjusted for the
time between receiving the last server message and sending this message.
Timestamp_microseconds: 32 bits
The microseconds part of the last server timestamp sent, adjusted as above.
Client Random Number: 256 bits
A 32-byte random number chosen by the client used to derive the master
secret key between the server and each client.
Key Info: varies
Either the premaster secret key selected by the client, encrypted with the
server's RSA public key, or 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, or if the
server requests RSA/ECDSA signatures instead of HMAC.
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 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 RSA or ECDSA public key.
Signed Verify Data: varies
The signature from the client's RSA/ECDSA private 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