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






                           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"
