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
|
+-----------------------------------------------------------------------------+
NPING ECHO PROTOCOL
PROTOCOL SPECIFICATION
Request for Comments
July 2009
Luis MartinGarcia
(luis.mgarc@gmail.com)
+-----------------------------------------------------------------------------+
PREFACE
This document introduces Nping Echo Protocol, the protocol that has been
designed to support a new feature that allows Nping users to see what the
packets they send look like when they reach their destination.
TABLE OF CONTENTS
1. INTRODUCTION ..................................................... x
2. NPING ECHO PROTOCOL SPECIFICATION................................. x
2.1 General Packet Format.............. ........................... x
2.2 Field Description ............................................. x
2.3 Operation Codes ............................................... x
2.4 Operation HELLO................................................ x
2.5 Operation HELLO RESPONSE ...................................... x
2.6 Operation SPECS ............................................... x
2.7 Operation READY ............................................... x
2.8 Operation ECHOPKT ............................................. x
2.9 Operation QUIT ................................................ x
2.10 Flow Diagram .................................................. x
2.11 Security .......................................................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 it's 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
hping can't track down the problem alone. One generally have to turn to
Wireshark/tcpdump on one station and hping 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 will have a mode called "Echo mode" (We are
still looking for a better name, suggestions are welcome), that will
give it the power of hping + tcpdump.
Both machines have to be running 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 Packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. DATA .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Checksum .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are 6 different kinds of packets:
HELLO: (C->S)
Informs the server of the highest version we support.
HELLO RESPONSE: (S->C)
Informs the client of the highest version we support.
SPECS: (C->S):
Tells the server what kind of packets we are planning to send.
READY: (S->C):
Tells the client that the server is ready to start receiving
packets.
ECHOPKT: (S->C):
Contains the packet that the server receives from the client.
QUIT: (C->S or S->C):
Asks to stop the echo process.
2.2 Field Description
Version: 8 bits
Current version of the protocol. This document covers version 0x01.
Operation Code: 8 bits
Indicates the type of packet. It must be one of the operation
codes defined in section 2.2.
Total Length: 16 bits
Length of the entire packet, measured in 32bit words. Value must
be in NETWORK byte order.
Sequence Number: 32 bits
Initially each peer generates a random sequence number and then
increments it by one in each packet that it sends. It must be
in NETWORK byte order. This field is intented to provide some,
very basic, protection against replay attacks.
Reserved: 64 bits
Reserved for future use. Reserved fields have been added for two
reason. 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
Operation specific data.
Checksum: 256 bits
SHA-256 sum of the entire packet. Checksum computation includes
the checksum field which must be previously set to zero.
This field is intended to provide client authentication. Echo
messages are transmitted encrypted (unless Nping is compiled
without OpenSSL). When a server receives a packet, it decrypts it
using a symmetric key known by both ends. Then it verifies the
checksum. If the checksum is correct it assumes the client is
an authorized user because only a person who knows the encryption
key and is capable of generating packets that when decrypted
produce valid sums.
2.3 Operation Codes
Operation HELLO: 0x01
Operation HELLO RESPONSE: 0x02
Operation SPECS: 0x03
Operation READY: 0x04
Operation ECHOPKT: 0x05
Operation QUIT: 0x06
2.4 Operation HELLO
The HELLO packet is sent by the client and it asks the server
to establish a new session. The packet also informs the server
of the latest version of the protocol that the client supports.
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 | OP Code 0x01 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved | IP version |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- Partner IP address --+
| |
7 +-- --+
| |
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
9 +-- --+
| |
10 +-- Reserved --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Version: 8 bits
IP version of the following IP address.
Partner IP address: 128 bits
This is the server's IP address as seen by the client. This is
not very useful but is provided for consistency with the HELLO
response packet.
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.
Reserved: 128 bits
Reserved for future use.
2.5 Operation HELLO RESPONSE
The HELLO RESPONSE packet is sent by the server to indicate the client
that he is actually a Nping Echo server and to inform about the
latest version it supports.
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 | OP Code 0x02 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved | IP version |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
5 +-- --+
| |
6 +-- Partner IP address --+
| |
7 +-- --+
| |
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
9 +-- --+
| |
10 +-- Reserved --+
| |
11 +-- --+
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Version: 8 bits
IP version of the following IP address.
Partner IP address: 128 bits
This is the client's IP address as seen by the server. This
lets the client to inmediatly detect the presence of some
intermediate device that changes his source IP (e.g a NAT box).
This can also be useful in case the client wants to specify
its own BPF filter (overriding server's default behaviour)
(see section 2.5 for more information).
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.
Reserved: 128 bits
Reserved for future use.
2.6 Operation SPECS
The SPECS packet is sent by the client to tell the server what kind
of packets it should expect. Additionally, the client may also include
a custom BPF filter for the server.
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 | OP Code 0x03 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved | Packet Count |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. | |
. . .
. . BPF filter specification .
n . .
| |
n+1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
n+9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol: 8 bits.
Specifies which kind of packets will be sent to the server. It
must contain one of the following values:
0x01 (Protocol TCP)
Tells the server to listen to TCP packets coming from
the client's IP address.
0x02 (Protocol UDP)
Tells the server to listen to UDP packets coming from
the client's IP address.
0x03 (Protocol ICMP)
Tells the server to listen to ICMP packets coming from
the client's IP address.
0x04 (Protocol ARP)
Tells the server to listen to ARP packets coming from
the client's MAC address (or in most cases, server's
gateway MAC address).
0xAA (Custom BPF filter included)
Tells the server to use a custom BPF filter specified in
an additional field.
0xFF (Any protocol)
Tells the server to listen to any packets coming from
the client's IP address.
Reserved: 8 bits
Reserved for future use.
Packet count: 16 bits.
Specifies how many packets will be sent. It must be in NETWORK
byte order.
BPF filter specification: variable length
When field "Protocol" contains value 0xAA, an additional
field is included in the packet: the BPF filter specification.
This field contains a BPF filter specification in tcpdump
format. This is useful when the client wants to override the
server's default BPF filters and capture a different type of
traffic.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPF Filter Spec Length | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. BFP Filter Spec .
. +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length is measured in bytes and should be in NETWORK byte
order. If the length is not a multiple of 16, it must be padded
with NULL bytes.
When client specifies an empty filter, meaning capture all
packets, the field will look like:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length=0 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As a security measure, the server may not allow use of
custom BPF filters. In that case, a QUIT packet must be
sent to the client.
2.7 Operation 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
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x04 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.8 Operation ECHOPKT
The ECHOPKT packet is sent by the server and it contains an echoed
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
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | OP Code 0x05 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLT Type | Packet Length |
5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . Packet .
. . .
n . +-+-+-+-+-+-+-+-+
| | Padding |
n+1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
n+9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Packet Length: 16 bits.
Specifies the length of the echoed packet measured in bytes.
It must be in NETWORK byte order.
Packet: variable length.
This corresponds to the packet being echoed. Server should
store the packet exactly as it was received. No byte order
conversions or any other alteration should be performed.
If the length is not a multiple of 16, it must be padded with
NULL bytes.
2.9 Operation QUIT
The QUIT packet is sent by client or server to tell its peer to
terminate the current session.
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 | OP Code 0x06 | Total Length |
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. . .
. . SHA256 Checksum .
. . .
| |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This packet should be sent:
By the client: to tell the server to stop echoing packets and
terminate the current session.
By the server: to tell the client that no custom BPF filter
is allowed so the session will be terminated.
2.10 Flow diagram
The following diagram represents a typical session:
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| HELLO | :: Hi. I'm an Nping Client.
|------------------>>| I support version 1.
| |
| |
| HELLO RESPONSE |
|<<------------------| :: Nice 2 meet u. Im a server..
| | I also support version 1
| |
| SPECS |
|------------------>>| :: I'll be sending 5 ICMP
| | Destination Unreachable probes.
| |
| |
| READY |
|<<-- ---------------| :: OK, I'm ready for those probes.
| |
| |
| |
| |
| ECHOPKT |
|<<------------------| :: Here's what I received.
| |
| ECHOPKT |
|<<------------------| :: Here's what I received.
| |
| ECHOPKT |
|<<------------------| :: Here's what I received.
| . |
| . |
| . |
| ECHOPKT |
|<<------------------| :: Here's what I received.
| |
| |
| |
| QUIT |
|------------------>>| :: It's been a pleasure.
The following diagram represents a session where the client requests
the use of a custom BPF filter but the server is configured not to
allow it.
+------+ +------+
|CLIENT| |SERVER|
+------+ +------+
| |
| HELLO | :: Hi. I'm an Nping Client.
|------------------>>| I support version 1.
| |
| |
| HELLO RESPONSE |
|<<------------------| :: Nice 2 meet u. Im a server..
| | I also support version 1
| |
| SPECS |
|------------------>>| :: Use this BPF filter (tcp and udp)
| |
| |
| |
| QUIT |
|<<-- ---------------| :: Sorry, no custom BPF allowed.
2.11 Security
The Nping Echo functionality involves direct access to network traffic
on the server side and that can easily involve information leakage
problems if no security measures are taken.
Unless Nping is compiled without OpenSSL support, all Nping Echo
Protocol (NEP) packets are transmitted encrypted. Rijndael/AES standard
is used. It has a block size of 128 bits, that's why all NEP packets
must have a length that is multiple of 16 bytes.
Every NEP packet includes a SHA-256 checksum. SHA-256 has been chosen
over MD5 or SHA1, just to be safe in the future. MD5 is already broken
and some studies show important advances in SHA1 attacks.
As described above, client authentication is performed using the
checksum field. The server assumes only a client in possesion of the
correct encryption key is capable of producing packets that, when
decrypted, contain valid SHA-256 checksum. However, replay attacks
may be possible in this scheme. A small 32bit Sequence field is
included in every packet. In theory, the server could have a list
of sequence numbers that have already been used and deny connection
to clients that use replayed packets. However, a 32 bit space may not
be sufficiently large to provide security, and exhaustion of sequence
numbers may result in a denial of service for authorized clients.
If we set the "Reserved" field (56 bits) in the initial HELLO packet
to some random value, and we instruct the server to keep a list of
both, sequence numbers and checksums, then it is possible that the
tuple (seq, checksum) provides enough security while significantly
reducing the possibility of client denial of service. We can even use
(seq, rand, checksum) where "rand" is the random data included in
the reserved space.
The problem with replay attacks is not tremendously important because,
at the end of the day, an attacker that does not have the encryption
key and therefore cannot see the contents of the ECHOPKT packets.
However, if the attacker replays old packets to establish a new
connection, the server will send him some data whenever he captures
a packet, and the fact the it has actually captured a packet can give
the attacker enough information to tell if the server is behind a
firewall, etc.
Security aspects are not yet defined properly. Any comments and
suggestions are welcome.
3. GLOSSARY
4. REFERENCES
[1]
[2]
[3]
[4]
|