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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
|
+-----------------------------------------------------------------------------+
NPING ECHO PROTOCOL
PROTOCOL SPECIFICATION
Request for Comments
August 2010
Luis MartinGarcia
(luis.mgarc@gmail.com)
+-----------------------------------------------------------------------------+
Status of this document: DRAFT
First version: May 29, 2009.
Last revision date: April 27, 2011.
+-----------------------------------------------------------------------------+
PREFACE
This documents presents the technical specification of the Nping Echo Protocol.
TABLE OF CONTENTS
1. INTRODUCTION ..................................................... x
2. NPING ECHO PROTOCOL SPECIFICATION................................. x
2.1 General Message Format......................................... x
2.2 Field Description.............................................. x
2.3 Message type codes............................................. x
2.4 Message NEP_HANDSHAKE_SERVER................................... x
2.5 Message NEP_HANDSHAKE_CLIENT................................... x
2.6 Message NEP_HANDSHAKE_FINAL.................................... x
2.7 Operation NEP_PACKET_SPEC...................................... x
2.8 Operation NEP_READY............................................ x
2.9 Operation NEP_ECHO............................................. x
2.10 Operation NEP_ERROR............................................ x
2.11 Flow diagrams.................................................. x
2.12 Security....................................................... x
2.13 Cryptographic key derivation................................... x
2.14 Encryption process............................................. x
2.15 Additional considerations...................................... x
3. GLOSSARY .......................................................... x
4. REFERENCES ........................................................ x
1. INTRODUCTION
Troubleshooting routing and firewall issues is a common task nowadays.
The scenario is generally that some network traffic should be flowing
but isn't. The causes of problem can range from routing issues to
network firewall to host-based firewalls to all sorts of other strange
things. It is usually the "middle box" problem that is the hardest to
find.
Suppose there is some host with a TCP service listening that you can't
connect to for an unknown reason. If a Nmap -sS scan doesn't show the
port as open there are a multitude of possible problems. Maybe the SYN
packet never made it because of some firewall in the middle. Maybe the
SYN did make it but the SYN+ACK got dropped on its way back to you.
Maybe the TTL expired in transit but the ICMP message got blocked by
another firewall before making it back to you. Maybe the SYN made it
but some intermediate host forged a reset packet to snipe the connection
before the SYN+ACK made it back to you.
When things like the above are going on it is often the case that even
nping can't track down the problem alone. One generally has to turn to
Wireshark/tcpdump on one station and nping on the other but sometimes
it may be quite difficult to coordinate, specially when the person at
the remote host does not even know what an IP address is.
To solve this problem, Nping implements a new mode of operation, called
"Echo mode", which provides a combination of a packet generator and a
remote sniffer.
The Echo mode is based on a client/server architecture. Both ends run Nping,
one of them in server mode and the other in client mode. The way it works
is: the Nping client performs an initial handshake with the server over some
standard port (creating a side-channel). Then it notifies the server
what packets are about to be sent. The server sets up a liberal BPF
filter that captures those packets, and starts listening. When the server
receives a packet it encapsulates it (including the link layer frame)
into our own protocol packet and sends it back to the nping client.
This would be essentially like running tcpdump on the remote machine
and having it report back the packets you sent to it with Nping.
By having the side-channel to talk to the server, things like NAT would
become immediately apparent because you'd see your source IP (and
sometimes port) change. Things like "packet shapers" that change TCP
window sizes transparently between hosts would turn up. It would be
easy to tell if the traffic is being dropped in transit and never gets
to the box. It would also be easy to tell if the traffic does make it
to the box but the reply never makes it back to you.
In general, it would be like sending a postal package to someone and
having them email you a photo of the package when they get it. If you
think your packages are being abused by the parcel service then having
someone on the other end to send information back is a great way to
uncover what is going on.
2. NPING ECHO PROTOCOL SPECIFICATION
2.1 General Message Format
The following diagram describes the general format of the NEP messages.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. DATA .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Message Authentication Code .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are 7 different kinds of packets:
NEP_HANDSHAKE_SERVER (S->C)
Informs the client of the highest version it supports and sends
the server's authentication parameters.
NEP_HANDSHAKE_CLIENT (C->S)
Informs the server of the highest version it supports and sends
the initial authentication parameters.
NEP_HANDSHAKE_FINAL (S->C)
Echoes server nonce back to the server.
NEP_PACKET_SPEC: (C->S):
Tells the server what kind of packets we are planning to send.
NEP_READY: (S->C):
Tells the client that the server is ready to start receiving
packets.
NEP_ECHO: (S->C):
Contains the packet that the server receives from the client.
NEP_ERROR: (C->S or S->C):
Indicates an error and terminates the session.
2.2 Field Description
Version: 8 bits
Current version of the protocol. This document covers version 0x01.
Message type: 8 bits
Integer that indicates the type of packet. It must be one of the
type codes defined in section 2.3.
Total Length: 16 bits
Length of the entire packet, measured in 32bit words. Value must
be in NETWORK byte order.
Sequence Number: 32 bits
Packet sequence number, relative to the sender. Initially this
field is set to a random value, and then it is incremented by one
for each packet that is sent in a given session. The counter must
wrap back to zero after it reaches (2^32)-1. This field is intended
to provide flow tracking and basic protection against replay
attacks.
Timestamp: 32 bits
Current time of the sender. This time is expressed as the number
of seconds elapsed since 00:00, 01/01/1970 UTC (epoch time).
Reserved: 32 bits
Reserved for future use. Reserved fields have been added for two
reasons: to allow future extension of the protocol and to make
the header a multiple of 128 bits needed to satisfy AES encryption
requirements in block size.
Data: variable length
Message specific data.
Message Authentication Code : 256 bits
Code that provides integrity and authentication to the rest of the
packet. For this, the HMAC-SHA256 suite must be used. The
computation of the code includes the whole plain-text message until
the first byte of the Message Authentication Code field.
2.3 Message type codes
Message NEP_HANDSHAKE_SERVER: 0x01
Message NEP_HANDSHAKE_CLIENT: 0x02
Message NEP_HANDSHAKE_FINAL: 0x03
Message NEP_PACKET_SPEC: 0x04
Message NEP_READY: 0x05
Message NEP_ECHO: 0x06
Message NEP_ERROR: 0x07
2.4 Message NEP_HANDSHAKE_SERVER
The NEP_HANDSHAKE_SERVER message is sent by the server and it requests
client's authentication. The packet informs the client of the latest
version of the protocol that the server supports and provides the
appropriate information for the client authentication process.
The NEP_HANDSHAKE_SERVER message establishes the following:
- The identity of the server and that the message was generated
by that server.
- That the message was intended for the client.
- The integrity and originality of the message.
The format of the NEP_HANDSHAKE_SERVER message is the following:
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
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- --+
| |
7 +-- --+
| Server Nonce |
8 +-- --+
| |
9 +-- --+
| |
10 +-- --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
13 + --+
| |
14 +-- Reserved --+
| |
15 +-- --+
| |
16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . Message Authentication Code .
. . .
| |
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Nonce: 256 bits
Random number. This number must be generated using a
cryptographically secure PRNG and must not be reused. This is
the data that should be used by the client to construct its
cipher block initialization vector.
Reserved: 120 bits
Reserved for future use.
HMAC-SHA256: 256 bits
Message authentication code that covers the entire packet, from
byte 0 to the last byte of the last reserved field. The code is
computed over the plaintext, before the encryption is applied to
part of the packet.
2.5 Message NEP_HANDSHAKE_CLIENT
The NEP_HANDSHAKE_CLIENT message is sent by the client and it provides
the appropriate information for client-side authentication. This type
of message is generated only if the previous NEP_HANDSHAKE_CLIENT
message contains a valid message authentication code.
The NEP_HANDSHAKE_CLIENT message establishes the following:
- The identity of the client and that reply message has been
generated by the client.
- That the message was intended for the server.
- The integrity and originaltity of the reply.
The format of the NEP_HANDSHAKE_CLIENT message is the following:
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
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- --+
| |
7 +-- --+
| Server Nonce |
8 +-- --+
| |
9 +-- --+
| |
10 +-- --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
13 +-- --+
| |
14 +-- --+
| |
15 +-- --+
| Client Nonce |
16 +-- --+
| |
17 +-- --+
| |
18 +-- --+
| |
19 +-- --+
| |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
###################### ENCRYPTION STARTS HERE #######################
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
21 +-- --+
| |
22 +-- Partner IP address --+
| |
23 +-- --+
| |
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Version | |
25 +---------------+ --+
| |
26 +-- Reserved --+
| |
27 +-- --+
| |
28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
####################### ENCRYPTION ENDS HERE #######################
28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . Message Authentication Code .
. . .
| |
36 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Server Nonce: 256 bits
Nonce value received from the server in the previous
NEP_HANDSHAKE_SERVER message. This allows the server to ensure that
the received reply is fresh and was generated as a result of its
NEP_HANDSHAKE_SERVER message.
Client Nonce: 256 bits
Random number. This number must be generated using a
cryptographically secure PRNG and must not be reused. This is
the data that should be used by the server to construct its
cipher block initialization vector.
Partner IP address: 128 bits
This is the server's IP address as seen by the client. This field
has 128 bits to allow use of both IPv4 and IPv6 addresses. When
IPv4 is used, only the first four bytes are used. The rest may be
set to zero or filled with random data.
IP version: 8-bits
Version of the address in the "Partner IP address" field. It should
take one of the following values:
0x04 : for IP version 4.
0x06 : for IP version 6.
2.6 Message NEP_HANDSHAKE_FINAL
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
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- --+
| |
7 +-- --+
| Client Nonce |
8 +-- --+
| |
9 +-- --+
| |
10 +-- --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
###################### ENCRYPTION STARTS HERE #######################
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
13 +-- --+
| |
14 +-- Partner IP address --+
| |
15 +-- --+
| |
16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Version | |
17 +---------------+ --+
| |
18 +-- Reserved --+
| |
19 +-- --+
| |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
####################### ENCRYPTION ENDS HERE ########################
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . Message Authentication Code .
. . .
| |
28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Client Nonce: 256 bits
Nonce value received from the client in the preceding
NEP_HANDSHAKE_CLIENT message.
Partner IP address: 128 bits
This is the clients's IP address as seen by the server. This field
has 128 bits to allow use of both IPv4 and IPv6 addresses. When
IPv4 is used, only the first four bytes are used. The rest may be
set to zero or filled with random data. The inclusion of this
information lets the client immediately detect the presence of
some intermediate devices that change his source IP (e.g a NAT box).
This is a modification of the original X.509 three way
authentication protocol, provided, among other things, in order to
make the man-in-the-middle attack described in [1] more difficult.
IP version: 8 bits
Version of the address in the "Partner IP address" field. It should
take one of the following values:
0x04 : for IP version 4.
0x06 : for IP version 6.
2.7 Operation NEP_PACKET_SPEC
The NEP_PACKET_SPEC message is sent by the client to tell the server
what kind of packets it should expect.
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
###################### ENCRYPTION STARTS HERE #######################
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP version | Protocol | Packet Count |
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. | |
. . .
. . PacketSpec .
n . .
| |
32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
####################### ENCRYPTION ENDS HERE ########################
32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . Message Authentication Code .
. . .
| |
40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP version: 8 bits
Specifies which is the expected IP version. It must contain one
of the following values:
0x04 (IP version 4)
0x06 (IP version 6)
0xFF (Any version)
Protocol: 8 bits.
Specifies which kind of packets will be sent to the server. It
must contain one of the following values:
0x06 (Protocol TCP)
Tells the server to listen to TCP packets coming from
the client's IP address.
0x11 (Protocol UDP)
Tells the server to listen to UDP packets coming from
the client's IP address.
0x01 (Protocol ICMP)
Tells the server to listen to ICMP packets coming from
the client's IP address.
Packet count: 16 bits.
Specifies how many packets will be sent. It must be in NETWORK
byte order.
PacketSpec: 864 bits.
Tells the server which header fields should be checked to match
a captured packet with the client that sent it. This is necessary
as the server supports multiple user sessions at a time, and needs
a way to distinguish the packets.
The PacketSpec field consists of a list of protocol fields and
their expected value. Every item on that list has the following
format:
{Field Code, Field Value}
Where "Field Code" is an 8-bit numeric identifier of the field (see
definitions below) and "Field Value" is the expected value, that
the server should try to match. The length of "Field Value" depends
on the "Field Code" (see table below for details) and, in general,
it matches the usual length for that field int its original
protocol header.
Items on the PacketSpec list are specified sequentially. However,
the final length of the list must be 108 bytes, so null bytes must
be added after the last item.
The following table lists the available field specifiers, their
code and the length of their values.
====NAME======== ==CODE== ==LENGTH==
+----------------+--------+----------+
| IPv4_TOS | 0xA0 | 8 bits |
+----------------+--------+----------+
| IPv4_ID | 0xA1 | 16 bits |
+----------------+--------+----------+
| IPv4_FRAGOFF | 0xA2 | 16 bits |
+----------------+--------+----------+
| IPv4_PROTO | 0xA3 | 8 bits |
+----------------+--------+----------+
+----------------+--------+----------+
| IPv6_TCLASS | 0xB0 | 8 bits |
+----------------+--------+----------+
| IPv6_FLOW | 0xB1 | 24 bits |
+----------------+--------+----------+
| IPv6_NHDR | 0xB2 | 8 bits |
+----------------+--------+----------+
+----------------+--------+----------+
| TCP_SPORT | 0xC0 | 16 bits |
+----------------+--------+----------+
| TCP_DPORT | 0xC1 | 16 bits |
+----------------+--------+----------+
| TCP_SEQ | 0xC2 | 32 bits |
+----------------+--------+----------+
| TCP_ACK | 0xC3 | 32 bits |
+----------------+--------+----------+
| TCP_FLAGS | 0xC4 | 8 bits |
+----------------+--------+----------+
| TCP_WIN | 0xC5 | 16 bits |
+----------------+--------+----------+
| TCP_URP | 0xC6 | 16 bits |
+----------------+--------+----------+
+----------------+--------+----------+
| ICMP_TYPE | 0xD0 | 8 bits |
+----------------+--------+----------+
| ICMP_CODE | 0xD1 | 8 bits |
+----------------+--------+----------+
+----------------+--------+----------+
| UDP_SPORT | 0xE0 | 16 bits |
+----------------+--------+----------+
| UDP_DPORT | 0xE1 | 16 bits |
+----------------+--------+----------+
| UDP_LEN | 0xE2 | 16 bits |
+----------------+--------+----------+
+----------------+--------+----------+
| PAYLOAD_MAGIC | 0xFF | Variable |
+----------------+--------+----------+
The PAYLOAD_MAGIC type lets the client specify some magic number
included in the packet's payload. This can be used when all other
specifiers fail (e.g: in IPv4-to-IPv6 tunnels). The length of
its field data is variable and must be specified right after the
field code. Note that the length can never be higher than the
remaining space in the PacketSpec field. If no other field
specifiers are set, "length" can never be higher than 106 bytes.
Servers should carefully check the structure of the PacketSpec
field and close the session established with the sender if it
does not meet the requirements specified in this document.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAYLOAD_MAGIC | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PAYLOAD_MAGIC: 8 bits.
Field code. MUST be set to 0xFF.
Length: 8 bits.
Length of the data in the "Value" field. MUST be greater
than zero; MUST NOT be greater than the remaining space in
the PacketSpec field and MUST NEVER exceed 106 bytes.
Value: variable length.
Payload data. Its length must be the one specified in the
"Length" field. It may contain any binary value. Comparisons
at the server side should be made at the bit level so the
encoding should match the one used at the application layer
in the packets that are produced and sent by the client.
Here is an example of how a typical specifier list looks like:
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4_TOS | 0x00 | IPv4_ID | 0xCA |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFE | IPv4_PROTO | 0x06 | TCP_SPORT |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x4432 | TCP_DPORT | 0x00 |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x50 | TCP_FLAGS | 0x08 | TCP_SEQ |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x5D33FA6D |
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x00 | 0x00 |
6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x00 | 0x00 |
27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All packet specifications MUST include the IPv4_ID specifier
(or IPv6_Flow for IPv6) and at least three other fields specifiers.
Additionally, clients MUST NEVER specify the same field specifier
more than once in a NEP_PACKET_SPEC message. Clients that send
messages that do not meet these requirements MUST be rejected by the
server.
2.8 Operation NEP_READY
The READY packet is sent by the server to indicate the client that
his SPECS packet was accepted and that everything is ready to start
receiving and echoing packets.
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
###################### ENCRYPTION STARTS HERE #######################
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
####################### ENCRYPTION ENDS HERE ########################
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . Message Authentication Code .
. . .
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.9 Operation NEP_ECHO
The NEP_ECHO message is sent by the server and it contains an echoed
network packet.
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
###################### ENCRYPTION STARTS HERE #######################
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLT Type | Packet Length |
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. . Packet .
. . .
. . +-+-+-+-+-+-+-+-+
| | Padding |
n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
####################### ENCRYPTION ENDS HERE ########################
n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . Message Authentication Code .
. . .
| |
n+8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DLT Type: 16 bits.
Specifies the type of link layer device used in the server side.
Since the server includes link layer frames in echoed packets,
the client needs to know the DLT in order to process link layer
header information. Values used in this field must match DLT types
defined in libpcap and must be transmitted in NETWORK byte order.
Servers may use the special value 0x0000 to indicate that no link
layer header is included.
Packet Length: 16 bits.
Specifies the length of the echoed packet measured in bytes.
The value stored in this field must be in NETWORK byte order and
must never be greater than 9212, as that is the maximum number of
bytes that can be echoed per packet.
Packet: variable length.
This corresponds to the packet being echoed. Servers should
store the packet exactly as it was received. No byte order
conversions or any other alteration should be performed.
The whole NEP_ECHO packet must have a length that is a multiple of
16 bytes, so if (packet_len+4)mod16 is not zero, the packet field
must be padded with NULL bytes. As noted before, the maximum length
for an echoed packet is 9212 bytes. Any packet that exceeds that
length must be truncated.
2.10 Operation NEP_ERROR
The NEP_ERROR packet is sent by client or server when an error occurs,
and informs the other end that the sender is terminating the NEP
session and closing the TCP connection. This message includes an error
description string that should explain the reason why the session is
being terminated (e.g. authentication failed, invalid message format).
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
###################### ENCRYPTION STARTS HERE #######################
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. . Error Message .
. . .
. . .
| |
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
####################### ENCRYPTION ENDS HERE ########################
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . Message Authentication Code .
. . .
| |
32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error Message: 640 bits.
Contains a NULL-terminated ASCII string that describes the reason
why the session is being terminated by the sender. The string MUST
contain a NULL character (0x00) at the end of it. The remaining
bytes, if any, must also be set to zero.
2.11 Flow diagrams
The following diagram shows a typical client/server session:
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| NEP_HANDSHAKE_SERVER |
|<<---------------------|
| |
| |
| NEP_HANDSHAKE_CLIENT |
|--------------------->>|
| |
| |
| NEP_HANDSHAKE_FINAL |
|<<---------------------|
| |
| |
| |
| NEP_PACKET_SPEC |
|--------------------->>|
| |
| |
| |
| NEP_READY |
|<<---------------------|
| |
| |
| |
| |
| NEP_ECHO |
|<<---------------------|
| |
| NEP_ECHO |
|<<---------------------|
| |
| NEP_ECHO |
|<<---------------------|
| . |
| . |
| . |
| NEP_ECHO |
|<<---------------------|
| |
| |
| |
| TCP Connection Close |
|<<------------------->>|
The following diagram represents a session where the client sends an
invalid PacketSpec message.
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| NEP_HANDSHAKE_SERVER |
|<<---------------------|
| |
| |
| NEP_HANDSHAKE_CLIENT |
|--------------------->>|
| |
| |
| NEP_HANDSHAKE_FINAL |
|<<---------------------|
| |
| |
| |
| NEP_PACKET_SPEC |
|--------------------->>|
| |
| |
| NEP_ERROR |
|<<---------------------|
| |
| TCP Connection Close |
|<<------------------->>|
The following diagram represents a session where the server fails to
provide a valid NEP_HANDSHAKE_SERVER message.
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| NEP_HANDSHAKE_SERVER |
|<<---------------------|
| |
| |
| TCP Connection Close |
|<<------------------->>|
The following diagram represents a session where the client fails to
provide a valid NEP_HANDSHAKE_CLIENT message.
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| NEP_HANDSHAKE_SERVER |
|<<---------------------|
| |
| |
| NEP_HANDSHAKE_CLIENT |
|--------------------->>|
| |
| |
| TCP Connection Close |
|<<------------------->>|
2.12 Security
The NEP client/server authentication process is based on the three-way
authentication protocol, described in CITT recommendation X.509 [2].
However, it has been slightly modified:
- Messages are not signed using public-key cryptography but a
symmetric encryption key known by both client and server. This
provides the same authentication as the original specification
but it does not provide non-repudiation.
- Ciphertext is encrypted using the secret key shared by client and
server, instead of using the receiver's public key.
The cipher suite to be used for data encryption is AES-128.
When one of the two participating entities receives a fully encrypted
message (any message other than NEP_HANDSHAKE_SERVER, NEP_HANDSHAKE_CLIENT
or NEP_HANDSHAKE_FINAL), it performs the following steps:
1. Reads 128 bits and decrypts them.
2. Checks that version equals 0x01
3. Checks that the value in the message type field corresponds to a
valid message type code.
4. If message type is not one of NEP_HANDSHAKE_CLIENT or
NEP_HANDSHAKE_SERVER, it checks that the received sequence number
matches the last received sequence number from the same sender plus
one.
5. It checks that the received timestamp is inside a "reasonable" time
window (where "reasonable" is left undefined on purpose, as it may
vary depending on the nature of the implementation or the host
system).
6. Checks the received total length. For messages whose length is
fixed, it should check whether the received length matches the
expected length of the message. For variable length messages, it
should check that the length is at least, higher than or equal to the
minimum length for that kind of message.
7. If all tests succeed, then the remaining bits are read
(remaining = TotalLength - 128bits)
8. Any remaining ciphertext is decrypted.
9. An alternative message authentication code is computed over the
unencrypted data and matched against the received one. If both codes
match, then the message is considered valid (its integrity has been
verified and its contents are to be trusted), authentic (the creator
of the message is someone who knows the secret) and fresh (the
message is new and has not been replayed).
2.13 Cryptographic key derivation.
Five cryptographic keys are generated for each client session. All of
them are derived from a single shared secret (a passphrase), known by
client and server. The key derivation process is the following:
h=SHA256( "passphrase" + NONCES + KEY_TYPE_ID )
do(1000 times){
h=SHA256(h);
}
Where 'h' is a 256bit buffer that holds the final key, 'SHA256' is the
hash computation function for the SHA-256 algorithm, 'NONCES' is the
combination of server's and client's nonce values, exchanged during
handshake, and KEY_TYPE_ID is a string that varies depending on the
type of key being derived. (See below for its definitions).
As mentioned above, a total of 5 symmetric keys are used. Those keys
are:
NEP_KEY_MAC_S2C : Key used by the server to sign its messages.
For this type of key, KEY_TYPE_ID="NEPkeyforMACServer2Client"
(unquoted) and NONCES equals the server nonce in the
NEP_HANDSHAKE_SERVER message, concatenated with the client nonce
in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE).
NEP_KEY_MAC_S2C_INITIAL : Key used by the server to sign its
NEP_HANDSHAKE_SERVER messages. This is a special case key because
it needs to be generated before a client nonce is received (this is
the only key that is not influenced by the client's nonce). For
this type of key, KEY_TYPE_ID="NEPkeyforMACServer2ClientInitial"
(unquoted) and NONCES equals the nonce in the NEP_HANDSHAKE_SERVER
message, concatenated with an empty client nonce, in other words,
a nonce with all its bits set to zero (SERVER_NONCE + ZEROED_NONCE).
NEP_KEY_MAC_C2S : Key used by the client to sign its messages.
For this type of key, KEY_TYPE_ID="NEPkeyforMACClient2Server"
(unquoted) and NONCES equals the server nonce in the
NEP_HANDSHAKE_SERVER message, concatenated with the client nonce
in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE).
NEP_KEY_CIPHERTEXT_C2S : Key used by the client to encrypt its
messages. For this type of key, KEY_TYPE_ID=
"NEPkeyforCiphertextClient2Server" (unquoted) and NONCES equals the
server nonce in the NEP_HANDSHAKE_SERVER message, concatenated with
the client nonce in the NEP_HANDSHAKE_CLIENT message
(SERVER_NONCE + CLIENT_NONCE).
NEP_KEY_CIPHERTEXT_S2C : Key used by the server to encrypt its
messages. For this type of key, KEY_TYPE_ID=
"NEPkeyforCiphertextServer2Client" (unquoted) and NONCES equals the
server nonce in the NEP_HANDSHAKE_SERVER message, concatenated with
the client nonce in the NEP_HANDSHAKE_CLIENT message
(SERVER_NONCE + CLIENT_NONCE).
When not all 256 bits are required, the last 256-N bits of key material
may be discarded, where N is the desired key length. This is, if less
than 256 of key material is needed, discarded bits must be the least
significant ones.
2.14 Encryption process.
Encryption must be performed using AES-128-CBC. This is, using the AES
encryption algorithm in CBC mode, with 128-bit keys.
For each party producing encrypted data, the first initialization
vector should be the nonce that this same party generated during the
authentication handshake phase. If the nonce has more bits than needed,
only the necessary number of bits should be used. These bits should be
the most significant ones.
The initialization vector for subsequent encryption operations should
be the last ciphertext block produced by the same entitiy. This is, to
encrypt the Nth message, the last ciphertext block of the (N-1)th
message should be used as the initialization vector for message N. Same
rule applies for decryption operations, where the initialization vector
should be the last ciphertext block received from the other end.
2.15 Additional considerations.
- By default, the server side will listen for incoming connections on
TCP port 9929.
3. GLOSSARY
C->S : Indicates that a given message is sent from the client to the server
S->C : Indicates that a given message is sent from the server to the client
NEP : Acronym for Nping Echo Protocol
4. REFERENCES
[1] I'Anson, C. and Mitchell, C. (1990). "Security defects in CCITT
recommendation X.509: the directory authentication framework". ACM
SIGCOMM Computer Communication Review, Volume 20, Issue 2. United
States.
[2] C.C.I.T.T. (1988). "Recommendation X .509, The Directory -
Authentication Framework"
|
