Re: ncat: using UDP with --chat

[David Fifield <david () bamsoftware com>]

On Mon, Nov 09, 2009 at 12:28:21AM +0100, clemens fischer wrote:
> > So, this is really the heart of the issue. Whatever the format of
> > the messages, the server has to somehow know what addresses to send
> > messages to. The wouldn't be an explosion of messages because we
> > would still enforce --max-conns, but we would end up sending messages
> > to addresses that no longer care about them. But so far no one has
> > offered an alternative implementation idea.
> >
> > But from your description of the server, I think that simple
> > connection brokering is not enough for what you want. Things like
> > having the server send back a list of recorded tags in response to a
> > ":" will require some domain-specific knowledge in the server. That
> > is, unless the "server" of this protocol is different from the Ncat
> > server, and connects to the Ncat server as a normal client. But then
> > you still have the problem of know who to relay messages to.
>
> I'm not sure how to handle this.  In my original concept the entity now
> to be realized by Ncat was only a broker, and it as the only one.  Each
> participant could serve and receive messages, and one could have made
> one of them an observer just logging and replaying (parts of) messages
> on request.  I needed a simple and robust system monitoring facility
> back then, without any domain or topology knowledge.
>
> Could Ncat in UDP brokering mode record all connecting clients together
> with the their last message and a sequence number?  What I originally
> wanted was like this:
>
>                       sender/
>   client message      response        Ncat behaviour
>   ------------------------------------------------------------
>   c-1    temp1: 33C   <N><S1><ok>     register c-1 as sender
>   c-2    :            <N><S2><ok>     register c-2 as observer
>   c-3    sick: yes    <N><S3><ok>     register c-3 as sender
>   c-4    temp1:       <C1><S1>33C     register c-4 as
>                                       interested in temp1
>   c-5    :            <C2><S2>temp1,  don't register c-5,
>                       sick            just make it aware
>   c-2    ::           <N><S4><ok>     unregister c-2
>   c-6    :            <N><S5><ok>     register c-6 as observer
>   c-7    :            <timeout>       nothing, expects c-6 to answer
>   c-6    ::           <N><S5><ok>     unregister c-6
>
>   legend:
>
>   <N>       sending party is Ncat
>   <Cn>      sending party is client-n
>   <timeout> nothing is sent, no state change, an error
>   <Sn>      sequence number, relates messages and clients
>   <ok>      no response text, but no error either
>
> In this example, c-2 and c-6 are special in that either could become an
> observer.  c-2 can handle it for some time and does so, c-6 can not and
> unregisters immediately.  There could be a client (c-7) asking for tags
> between the time c-6 asks, recognizes the new role it should fulfill and
> unregisters.  By that time Ncat has c-6 observer registered and expects
> it to answer, but this doesn't happen, as c-6 is not wired as an
> observer.
>
> The sequence numbers are meant for clients to know if the value they got
> sent is new or an old one.
>
> Clients registering successfully as senders  should store the sequence
> number from the response sent by Ncat, because they are responsible for
> sending it back once other clients ask for the information.

Thank you. This helps me understand better what you want to accomplish.
I think this kind of thing, which amounts to a new network protocol, is
more than Ncat brokering should do. I think it should, as much as
possible, be a transparent pipe that doesn't have to process data above
the TCP or UDP layer.

Have you thought about using TCP brokering mode for this? What you've
described above could be implemented with all the intelligence in the
clients. The : and :: messages would just be the beginning and end of
TCP connections. The hard part of all this is managing connections, and
TCP does that.

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