Re: ncat: using UDP with --chat

[David Fifield <david () bamsoftware com>]

On Thu, Oct 22, 2009 at 01:21:11PM +0200, clemens fischer wrote:
> > On Tue, Oct 13, 2009 at 07:08:32PM +0200, clemens fischer wrote:
> > > it said:
> > >
> > >   $ ncat -u -l 9999 --chat
> > >   Ncat: UDP mode does not support connection brokering.  If this
> > >   feature is important to you, write nmap-dev () insecure org with a
> > >   description of how you intend to use it, as an aid to deciding how
> > >   UDP connection brokering should work. QUITTING.
> > >
> > > My idea is to use UDP chat mode as a kind of emergency IPC mechanism
> > > together with "--allow" between cooperating processes on machines
> > > without eg. posix mesage queues.
> > >
> > > Connecting clients would tag their messages themselves, like:
> > >
> > >   $ echo "temperature1: 33C" | ncat -u localhost 9999
> > >
> > > Other clients would see and evaluate the entire line and respond in
> > > a similiar way.
> >
> > Cool, thanks for the note. One of the problems we've had in defining
> > connection brokering for UDP is knowing which clients to relay data
> > to.  When the Ncat broker receives the "temperature1: 33C" message,
> > where does it send it? Presumably it should be sent to all interested
> > processes, but the broker has to know about those somehow.
> >
> > One idea we've had is to consider any host that has ever sent UDP data
> > to the broker to be a "connected" client, perhaps with timeouts for
> > inactive hosts. This would require each participating process to "sign
> > in" by sending a message, to make the broker aware of them.
> >
> > Is that something that would work for you? It would help if you would
> > sketch more of the IPC architecture. You've shown how the clients will
> > send to each other; what do they do to receive?
>
> I was thinking about this a bit.  Currently I lean towards this idea:
>
> Messages are of two categories.  Every message starts with a tag,
> ending in a possibly configurable tag-separator.  After the
> tag-separator can be any text.  If that text is empty, the process is
> indicating interest in further messages of the "type" with this tag.
>
> Textual tag-separators in the tag have to be transmitted either escaped
> with the customary backslash or doubled, ie. given a colon as the
> tag-separator, "temp\:1:" might be a valid tag, or "temp::1:"
> (implementors choice).
>
> An implementation may choose to allow querying the messages available so
> far by sending an empty tag.  So, sending ":" alone would make the
> server send back the tags learned so far.  This is for monitoring or for
> "special clients".  It would be very nice if the hosts allowed to
> monitor such a network could be made configurable, but the --allow* and
> --deny* options should do fine.
>
> I like the idea of the timeouts for inactive hosts, but I fear that
> selecting by "connected on this UDP-port" alone could lead an explosion
> of message-load.

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.

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