diff options
Diffstat (limited to 'nping/nping-dev/EchoProtoRFC_v0.txt')
| -rw-r--r-- | nping/nping-dev/EchoProtoRFC_v0.txt | 741 |
1 files changed, 741 insertions, 0 deletions
diff --git a/nping/nping-dev/EchoProtoRFC_v0.txt b/nping/nping-dev/EchoProtoRFC_v0.txt new file mode 100644 index 0000000..65f1a88 --- /dev/null +++ b/nping/nping-dev/EchoProtoRFC_v0.txt @@ -0,0 +1,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] + + + + + + + |