Re: RFC: New Nping "Echo Mode"

[Fyodor <fyodor () insecure org>]

On Sun, Jun 27, 2010 at 11:37:40PM +0200, Luis MartinGarcia. wrote:
> As some of you may know already, Fyodor and I are currently working on a
> new exciting feature for Nping: the "Echo mode". What we are basically
> trying to do is to determine how the packets that Nping sends, look like
> when they reach their destination.

Hi Luis.  Thanks for writing and sending this nice RFC!  It is indeed
an exciting feature!

>     To solve this problem, Nping will have a new mode, called "Echo mode"

In some ways I like the name "echo mode", but in other ways I'm
concerned that it is a bit confusing.  After all, the normal ping
("echo request") functionality performed by Nping is at least as much
like an echo as this is.  Admittedly I don't have any better names in
mind.  But if someone else does, they should speak up.

>     that will give it the power of a combination like hping + tcpdump.

Like nping + tcpdump :).

>  SERVER 
>     Users may start the server, using the default parameters, running:
>         nping --echo-server
>
>     Obvioulsy it would be possible to override defaults running something like:
>         nping --echo-server --echo-port 9999 -vvv --passphrase "Squemmish Ossifrage"

There should probably be an echo server option which tells it to only
handle one nping echo client connection and then quit.  That way you
don't risk forgetting to turn it off afterward.

We could consider short alternative options for --echo-server and
--echo-client if you think of any.  I was thinking -C and -S, but we
already use -S for source IP address.

>     Users would need to supply "--echo-client" and a list of packets to send.
>     There would be a new command line parameter, "-P", whose argument should be
>     the list of options that define the packet. This options would be the same
>     ones used for the Nping normal operation mode.
>
>     For example, the next command tells nping to connect to the echo server at
>     echo.insecure.org, and send two TCP-SYN packets and one ICMP echo reply to
>     the echo server.
>     
>         nping --echo-client --passphrase "Squemmish Ossifrage" -P"{--tcp --flags psh,ack --win 0 -c2 }" -P"{--icmp 
> --icmp-type echo-reply --icmp-seq 3}" echo.insecure.org 

Why don't we just specify those options directly, the same way we
normally do with Nping?  If we want to do two sets, couldn't we run
two echo-clients?  Or add a normal nping feature for sending multiple
different packet types.

The echo client will have to pass information to the server so it
knows what to look out for.  We'll have to think about how the server
will be able to recognize and demultiplex the packets from each
stream.

> 1. Nping could do something similar to its regular mode, where it prints
>    sent and received packets line by line, only that this time, there are
>    no received packets but "captured" packets, received from the side channel.
>    The output could be something like this:

Maybe we should print received packets too?  It would be nice if we
could get the order right.  Maybe Nping could get the time from the
server and calculate an offset from its own time to try and order the
various packets.

I like the idea of printing in the same format Nping already uses for
SENT/RCVD packets.

> 2. Alternatively, Nping could only display, for captured packets, the fields
>   that changed in transit. This would look like this:

Printing the differences below the captured packet sounds like it
might be a good idea too.  To print differences, the client would have
to match up the captured packet with the appropriate sent packet.  But
that shouldn't be terribly hard.  I suppose if we're printing
differences, maybe we could omot the normal packet content display,
though we'd need a good way to match it up to the sent packet in the
interface too.

I imagine that in most real-life cases, the user won't be sending
packets too quickly and so it will be obvious which captures packet
corresponds to which send.

One option is to show the CAPT line just as we would any sent/rcvd
packet, but then also highlight any changes below that line (e.g. src
address changed from 192.168.0.40 to 23.197.4.53).  How to present
this to the user definitely warrants a bit more thought.

> 3. Nping could print sent and captured packets, side by side, using
> RFC-like format. The following diagram illustrates this: (note that
> only IP header is shown in this example but trannsport layer headers
> would also be printed in a real execution):

My feeling is that if we decided to have a mode like that for normal
packets, we could also implement it for echo mode.  But I don't think
we need to add this for echo mode, as it could be used to visualize
sent/rcvd packets just as easily.

> Check that both         |                          |
> understand each other   |  NEP Handshake and Auth  |
> and authenticate the    |<------------------------>|
> client                  |<------------------------>|
>                         |<------------------------>|

I agree with Drazen that we need to think about the auth protocol and
algorithms used.

>                         |                          |
>                         |    Terminate Session     |
> Client indicates that   |------------------------->|
> is going to stop        |                          |
> sending packets         |                          |
>                         |                          |
>                         |   ACK Terminate Session  |
> Server confirms         |<-------------------------|
>                         |                          |
>                         |                          |
>                         |  TCP Connection Close    |
> TCP connection closed   |<------------------------>|

I wonder if the client can just close the connection when it is done?
Or does an explicit termination command help in some way?

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