On 7/4/05, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
> A good place to start I think would head over to the tcpdump.org folks
> which maintain pcap (not all of them read this mailinglist since this
> is merely for one out of many applications using libpcap).
Yes, I am trying to do that. However, I might need some help getting
in contact with the "tcpdump.org" folks. The mailing list archive
linked on the web page ends at the beginning of the year. Is there a
newer one? And I have successfully subscribed to tcpdump-worker (which
should be right mailing list), but I do not receive my own message. Is
the list set up not to send messages to myself (very bad idea, imho)?
Or is something stuck there?
> Since they have previously raised well founded concerns about other
> proposals complete lack of security good questions to start with
> would be :
KISS. A basic form of authentication should be possible, everything
else should be delegated to a better tool like ssh.
> What requirements would you say are absolute requirements for this to
> ever be accepted?
Good question. I just asked that (or maybe not? :-)).
> Since any additions of this kind would affect the codebase for libpcap
> and might introduce extra dependencies to libpcap, what options are
> available to ensure maximum interoperability and support for this for
> the platforms libpcap support?
I would not worry too much about that, since libpcap is by its nature
much less portable than easy networking stuff. But the question is
still valid, especially because UNIX/Windows interoperability would be
nice.
> Since security and network interconnect would by definition require
> additional code in libpcap, would something like the semi-standard
> ONC-RPC/GSS-API be sufficent?
KISS: why do we need an encapsulation? For remote capture, sending
libpcap format over a network connection is absolutely sufficient.
> 1, write a protocol specification
Libpcap, sent using separate UDP datagrams for file header and each
packet. Javier uses a TCP connection initiated by Ethereal/libpcap for
the same purpose, but I would favour a connection initiated by the
remote side, if a connection is used. Winpcap supports both ways,
which is imho a violation of KISS.
> 2, write a specification how configuration and
> authentication/authorization data is to be stored on each side.
With UDP, I could imagine a filter on the source IP address. It would
be specified together with the port number in the interface string.
But to be honest, I don't see much room for security in an environment
where developers are running ethereal as root. Especially passwords
are of very little use.
> 3, implement and show a patch for review.
To be done, as soon as I get the answers from tcpdump.org, and have
some time for it.
Thomas
