summaryrefslogtreecommitdiffstats
path: root/nping/nping-dev/echo_proposal.txt
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-17 07:42:04 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-17 07:42:04 +0000
commit0d47952611198ef6b1163f366dc03922d20b1475 (patch)
tree3d840a3b8c0daef0754707bfb9f5e873b6b1ac13 /nping/nping-dev/echo_proposal.txt
parentInitial commit. (diff)
downloadnmap-0d47952611198ef6b1163f366dc03922d20b1475.tar.xz
nmap-0d47952611198ef6b1163f366dc03922d20b1475.zip
Adding upstream version 7.94+git20230807.3be01efb1+dfsg.upstream/7.94+git20230807.3be01efb1+dfsgupstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'nping/nping-dev/echo_proposal.txt')
-rw-r--r--nping/nping-dev/echo_proposal.txt222
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 |<------------------------>|
+ | |
+
+
+
+
+
+