Re: Packet sanitization and IP masking (PR #615)

[Denis Ovsienko <denis () ovsienko info>]

 ---- On Wed, 13 Dec 2017 15:48:32 +0000 alice-cyberreboot <alice () 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