diff options
Diffstat (limited to 'nping/nping-dev/echo_proposal.txt')
| -rw-r--r-- | nping/nping-dev/echo_proposal.txt | 222 |
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 |<------------------------>| + | | + + + + + + |