Re: symmetry in nping echo protocol

["Luis MartinGarcia." <luis.mgarc () gmail com>]

Hi Toni,

Sorry for taking so long to respond to your email. Here are some of my
thoughts:


> > Would it make sense for the echo server to include information about
> > the message it is sending to the encrypted response packet, so one
> > could do some reasoning both ways by just looking at the client. 

This is something I considered last year, when I designed the protocol.
However, as
you noted in your second email, there are some challenges associated
with it.

The first problem is that the server has no easy access to the
responses, as they
are generated by the server's TCP/IP stack, and not by the echo server
itself.
However, responses could be sniffed and then sent to the client through the
side channel, just like we do with client packets. This is possible, but
not as easy
as it sounds, since the echo server would need to infer what kind of
packet the
server is going to generate as a reply. TCP-SYNs may generate
TCP-SYN|ACK but
also ICMP time exceeded, ICMP parameter problem, no response at all due to
local filtering, etc. If the echo server was isolated and did not
receive any other traffic
than the one generated by an Nping echo client, then we could just fire
up the sniffer
and send a copy of any received packets to the client. Unfortunately,
our scenario is
not that ideal. Echo clients can serve multiple clients at the same time
and can be installed
on servers that offer other network services as well. Also, clients
cannot be easily
identified by their source IP address since one user may run multiple
instances
of the echo client simultaneously, or many users may connect to the
server with the
same source IP because they are behind a NAT device.

We could, however, take another approach. We could use the client and
server
as we now do and then, just reverse the roles but keeping the same side
channel.
It would be something like this.

Let C be an Nping echo client and S be an Nping echo server:

C connects to S.
C sends packets to S.
S echoes packets to C.
C compares sent packets with the packets that the server captured and
echoed through the side channel.


Now,

C tells S that it finished sending packets.
S starts sending the same kind of packets to C.
S echoes the packet that is sending to C.
C captures S's packets and compares them with the packets obtained
through the side channel.


This would let the clients determine if the packets are being treated
the same way in both directions of the communications. One could find
that packets are being dropped in one direction but not on the other,
that packets are taking different routes, etc.

This is something I'll probably be working on in the next few months, so
stay tuned. I haven't studied this approach with enough detail so I'm
still not sure if it's possible to implement it or even if it's worthy,
but I'm open for discussion if you are interested on the topic.

Best regards,

Luis MartinGarcia.


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/