Bug #311
closed
Confusing option checksum_validation
Added by Pierre Chifflier over 13 years ago.
Updated almost 13 years ago.
Description
The option checksum_validation has strange side-effects, like disabling all App layer decoders when running on local traffic. This seems to be caused by the checksum offload on the NIC, making all packets have a checksum of 0 and get dropped.
Now, what is really annoying is that there is no warning on what is happening and no easy way to guess it. The result is also not the same, depending on the packet source:
- live pcap will drop packets silently
- nfqueue will work
Since this option could be considered harmful, I'd propose to disable it by default. Maybe also a big fat warning could be issued when using it on local traffic, or try to detect if offload is enabled ?
I don't think it's a good idea to disable by default. It would leave some reassembly attack options open that it's meant to prevent. Somehow detecting csum offloading in place is probably hard to do cross-platform... any other ideas?
What is really a problem here is to have tons of packets that disappear without being analyzed, and without any warning or any way to find the problem.
What is worse is also that this gives different behavior depending on the data source (pcap vs nfqueue).
And the option name is not easy the guess, looking at the symptom ..
So I'd say adding a warning if lots of packets are dropped due to incorrect checksum is a must-have (if not a solution, it would at least be a clue to find the cause of the problem).
If we're sure certain link types (like loopback) don't need checking we can probably bypass the checks for those links. Each packet has a datalink field (p->datalink) so that could help.
A counter of rejected packets because of csum would certainly be welcome.
In addition, a check that gives a one time warning, possibly with a link to a wiki page explaining the issue, after receiving e.g. 100 or 1000 packets with an invalid csum would help.
You interested in doing patches for these Pierre?
- Status changed from New to Assigned
- Assignee set to Eric Leblond
- Priority changed from Normal to Low
- Target version set to 1.2
- % Done changed from 0 to 30
Just created the counter for invalid csum tcp packets. Will be part of 1.1beta3.
Eric, can you come up with an idea/design for handling the per acquisition method oddities?
I've just done a study of the problem. Idea was to check if the different capture API provide way to detect that a packet is emitted and/or has an incomplete checksum.
If we consider the different modules:
- PF_RING: pfring_extended_pkthdr has a rx_direction which can be used to detect emitted packets
- AF_PACKET: packet has auxiliary data containing information about checksum completeness.
- pcap: Nothing is available here
PF_RING and AF_PACKET can be treated easily in an efficient way.
For pcap we need to find some alternative using for exemple hardware address.
A solution for pcap could be to used pcap_setdirection. This function provide a way to only accept RX packet or TX packet. By limiting to RX packet, the IDS will only capture the network traffic and that could be the wanted result.
One problem with this approach is that pcap_setdirection is said not to be implemented for all OS.
I don't think the pcap_setdirection usage would solve the problem though. We'd go from "can't track sessions because of broken tx csums" to "can't track sessions because of missing tx packets".
- Status changed from Assigned to Closed
- Target version changed from 1.2 to 1.2rc1
- % Done changed from 30 to 100
Eric's patchset applied, thanks!
Also available in: Atom
PDF