+-----------------------------------------------------------------------------+






                           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]







