Adding upstream version 7.94+git20230807.3be01efb1+dfsg.upstream/7.94+git20230807.3be01efb1+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 222 insertions, 0 deletions

diff --git a/nping/nping-dev/echo_proposal.txt b/nping/nping-dev/echo_proposal.txt
new file mode 100644
index 0000000..336202d
--- /dev/null
+++ b/nping/nping-dev/echo_proposal.txt
@@ -0,0 +1,222 @@
+
+
+                       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   |<------------------------>|
+                        |                          |
+
+
+
+
+
+