NPING NEW ECHO MODE PROPOSAL
                               June 2010

                           Luis MartinGarcia
                         (luis.mgarc@gmail.com)


 TABLE OF CONTENTS
 
     0x01. Introduction
     0x02. Input
     0x03. Output
     0x04. Results
     0x05. Protocol

== 0x01: 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 one
    has to turn to Wireshark/tcpdump on one station and Nping on the other.
    However, this is usually 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 new mode, called "Echo mode"
    that will give it the power of a combination like hping + tcpdump.
    This echo mode turns Nping into a client/server application. One station
    runs Nping 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 into a packet of our own protocol,
    the Nping Echo Protocol (NEP), and sends it back to the 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.



== 0x02: INPUT ==

 From a user's perpective, this new mode would be set up from the command line.
 Here's a possible interface:

 SERVER 
    Users may start the server, using the default parameters, running:
        nping --echo-server "Squemmish Ossifrage"

    where the parameter passed to the --echo-server argument is the passphrase
    that is used to derive encryption keys.

    Obvioulsy it would be possible to override defaults running something like:
        nping --echo-server "SquemmishOssifrage" --echo-port 9999 -vvv 

 CLIENT

    Users would need to supply "--echo-client <passphrase>" and the usual
    parameters used in Nping's normal operation mode.

    For example, the next command tells nping to connect to the echo server at
    echo.insecure.org, and send one TCP-SYN packet to the echo server.
    
        nping --echo-client "SquemmishOssifrage" --tcp --flags syn --win 0 -c1 echo.insecure.org

== 0x03: OUTPUT ==

 About the output, Nping will print three types of packets: sent packets,
 received reply packets, and echoed packets received through the side channel.
 For captured packets, only the fields that differ from the original packet will
 be displayed. This makes it easier to spot the fields that changed in transit.
 Here's a sample output.

 SENT (0.0980s) TCP 192.168.1.99:33856 > 74.207.254.18:80 S ttl=64 id=60467 iplen=40  seq=1754993861 win=0
 CAPT (0.4504s) TCP 10.1.2.158:33856 > 10.0.23.56:80 ttl=53
 RCVD (0.1000s) TCP 74.207.254.18:80 > 192.168.1.99:33856 SA ttl=128 id=11746 iplen=44  seq=3230736912 win=16384 <mss 1460>

 Output would be more detailed if verbosity mode is incremented. For example,
 the IP checksum, which is expected to change in virtually all cases (as it is
 recomputed in transit for every TTL decrement operation), would only be printed
 when the level of verbosity is higher than the default. Here's another example:

 SENT (0.0760s) TCP [192.168.1.99:33856 > 74.207.254.18:80 S seq=3835079997 ack=0 off=5 res=0 win=0 csum=0x807E urp=0] IP [ver=4 ihl=5 tos=0x00 iplen=40 id=63460 foff=0 ttl=64 proto=6 csum=0x2d6b]
 CAPT (0.4504s) TCP [10.1.2.158:33856 > 10.0.23.56:80 csum=34fd] [IP ttl=53 csum=f43d]
 RCVD (0.0850s) TCP [74.207.254.18:80 > 192.168.1.99:18367 SA seq=507544695 ack=3835079998 off=6 res=0 win=16384 csum=0x85F9 urp=0 <mss 1460>] IP [ver=4 ihl=5 tos=0x00 iplen=44 id=17102 foff=0 ttl=128 proto=6 csum=0xa27d]

 Note that the displayed time for the CAPT packet is higher than RCVD's. This is
 because Nping will hold the RCVD packet information until it gets the echoed
 packet. The reason for this behaviour is that it may be less confusing for end
 users to see the differences between the SENT and the CAPT packets if they
 are printed one after the other. Typically, network stacks will respond to
 SENT packets before the Nping Server has time to capture them, encapsulate them
 in a Nping Echo Protocol message and send them back to the client, so in order
 to display SENT and CAPT packets together, the RCVD output needs to be delayed
 for a bit.

== 0x04: RESULTS ==

 Apart from displaying the packets that were sent and the ones that were
 captured, Nping should, if possible, give hints about what may have happened
 in transit. For example, if the original source address does not match the
 source address of the received packet, Nping could inform that with high
 probability there is a NAT device close to the client. Nping could detect
 things like variation of TCP window size and warn about possible transparent
 proxies, etc.

 Starting Nping 0.5.30BETA1 ( https://nmap.org/nping ) at 2010-06-30 17:20 CEST
 
 SENT (0.0980s) TCP 192.168.1.99:33856 > 74.207.254.18:80 S ttl=64 id=60467 iplen=40  seq=1754993861 win=0
 CAPT (0.4504s) TCP 10.1.2.158:33856 > 10.0.23.56:80 ttl=53
 RCVD (0.1000s) TCP 74.207.254.18:80 > 192.168.1.99:33856 SA ttl=128 id=11746 iplen=44  seq=3230736912 win=16384 <mss 1460>

 Packet Echo Analysis:
  |_Source IP and Destination IP differ: possible NAT device on both ends.
  |_TTL values differ by 11 units. Network distance between both hosts: 11 hops.
 
 Max rtt: 8.509ms | Min rtt: 8.509ms | Avg rtt: 8.509ms
 Raw packets sent: 1 (40B) | Rcvd: 1 (46B) | Lost: 0 (0.00%)
 Echoed packets recv: 1 (40B) | Lost: 0 (0.00%)
 Tx time: 0.00020s | Tx bytes/s: 202020.20 | Tx pkts/s: 5050.51
 Rx time: 0.99984s | Rx bytes/s: 46.01 | Rx pkts/s: 1.00
 Nping done: 1 IP address pinged in 1.08 seconds


   
== 0x05: PROTOCOL ==

 The side channel will be run over a custom application layer protocol called
 NEP, Nping Echo Protocol. The protocol itself is described in a separate
 document: "Nping Echo Protocol Specification", available from:
    <https://nmap.org/svn/nping/nping-dev/EchoProtoRFC.txt>
    
 The following flow diagram describes a typical client/server interaction.
 Please refer to the document cited above for more information.


                        C                          S
                        |                          |
                        |       TCP Handshake      |
Establish regular TCP   |------------------------->|
connection              |<-------------------------|
                        |------------------------->|
                        |                          |
                        |                          |
                        |                          |
Check that both         |                          |
understand each other   |  NEP Handshake and Auth  |
and authenticate the    |<------------------------>|
client                  |<------------------------>|
                        |<------------------------>|
                        |                          |
                        |                          |
                        |                          |
Client tells the server |  PacketType={IP/TCP/Syn} |
which kind of packet is |------------------------->|
going so send           |                          |    S
                        |                          |    | /* Server starts    */
                        |                          |    | /* capturing packets*/
                        |      ServerReadyToGo     |    | /* here.            */
Server indicates its    |<-------------------------|    |
sniffing engine is      |                          |    |
readty to capture the   | C                        |    |
packet                  | |                        |    |
                        | |                        |    |
                        | |                        |    |
                        | |                        |    |
Client sends the pkt    | |    IP/TCP/Syn Packet   |    |
via raw sockets         | |---------------------------->| 
                        | |                        |    | /* Server receives  */
                        |                          |    | /* the packet       */
                        |    Echo of the packet    |....| 
Server echoes the       |<-------------------------|
packet via the NEP      |                          |
session they have.      |          .               |
                        |          .               |
                        |          .               |
                        |    More raw pkt/echo     |
                        |        exchanges         |
                        |          .               |
                        |          .               |
                        |          .               |
                        |                          |
                        |                          |
                        |  TCP Connection Close    |
TCP connection closed   |<------------------------>|
                        |                          |