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).
Since they have previously raised well founded concerns about other
proposals complete lack of security good questions to start with
would be :
What requirements would you say are absolute requirements for this to
ever be accepted?
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?
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?
Would inclusion and added dependency in libpcap on RPC/GSS-API be a
possible and acceptable path?
Then when everyone agrees that your bof seems possibly feasible and
possibly acceptable the next part of your work begins:
1, write a protocol specification
2, write a specification how configuration and
authentication/authorization data is to be stored on each side.
3, implement and show a patch for review.
On 7/4/05, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
> This functionality should go into libpcap/winpcap and not ethereal.
>
> I think it would be very difficult to get the pcap maintainers to
> accept something along these lines unless you add security (at a bare
> minimum proper authentication) to it.
>
>
> You should contact libpcap and winpcap folks and discuss the minimum
> requirements for getting a network/socket based capture mechanism
> implemented.
>
>
> An emperical observation is that
> while a lot of people request this functionality from time to time but
> no one yet has wanted it badly enough to put in some work to define
> the capture protocol and how security should be handled.
>
