Project

General

Profile

Bug #311

Confusing option checksum_validation

Added by Pierre Chifflier almost 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Low
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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 ?

#1

Updated by Victor Julien almost 9 years ago

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?

#2

Updated by Pierre Chifflier almost 9 years ago

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).

#3

Updated by Victor Julien almost 9 years ago

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?

#4

Updated by Victor Julien over 8 years ago

  • 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.

#5

Updated by Victor Julien over 8 years ago

Eric, can you come up with an idea/design for handling the per acquisition method oddities?

#6

Updated by Eric Leblond over 8 years ago

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.

#7

Updated by Eric Leblond over 8 years ago

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.

#8

Updated by Victor Julien over 8 years ago

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".

#9

Updated by Victor Julien over 8 years ago

  • 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