---- On Wed, 13 Dec 2017 15:48:32 +0000 alice-cyberreboot
<al...@cyberreboot.org> wrote ----
> Hello again,
>
> Here's a new update/summary of my PR:
>
> - Removed short options in favor of long ones for three features -
> zeroing out TCP/UDP payload in IPv4 packets (--zero-tcpudp-payload),
> removing said payloads completely (--no-tcpudp-payload), and masking
> external IP addresses to a given substitute IP (--mask-external-address
> mask_ip);
>
> - manpage documentation has been updated;
>
> - commits related to this PR have been consolidated into one commit
> message;
>
> - at the moment, currently up to date with upstream/master,
> including modifications resulting from ether.h being unavailable.
>
> Hope that at this stage, the PR is now ready for proper review.
>
> And again, if I can assist with work on fixing CVE-related issues, please
> let me know.
Hello all.
I have been thinking about the proposed design (making masking happen at the
capture time in the same binary), and there is a possible design issue that
bothers me.
Consider an end user with a really high rate/bandwidth capture rig. Their first
objective would be to copy the packets from the wire to the storage, as quickly
as possible to minimize the drops caused by the rig performance. The first
problem is, with the additional per-packet processing the performance will
drop, is that going to be visible?
The second objective would be to hand the capture over with masked endpoints,
but what if they have more than one receiver with different mask length, or the
mask length is later found to discard too many meaningful bits? It likely does
not mean they have to make a new capture each time they need a different mask
length.
I agree in some cases it is best to mask the endpoints right at the capture
time, but do you see the use case for offline masking (as in "tcpdump -r
infile.pcap -w outfile.pcap <masking parameters>")?
--
Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
