flow: optionally use pkt recursion for hash

[coledishington]

If a Suricata inline IPS device is routing traffic over a non-encrypted tunnel, like IPv6 tunnels, packets in a flow will be dropped and not be matched. e.g.

The following example is a Suricata inline IPS with an IPv6 tunnel:

request:  IPv4]ICMP] -> |IPS| -> IPv6]IPv4]ICMP]
reply:               <- |IPS| <- IPv6]IPv4]ICMP]

Both the IPv4 request and IPv6 reply will be seen by Suricata on
ingress. The flows will not be matched due to flow recursion level.

Optionally use pkt recursion level in flow hash. Excluding recursion level in flow hash allows matching of packet flows and defrag on an inline IPS Suricata scenario where the IPS device is a tunnel terminator.

Bug: #6260

Make sure these boxes are signed before submitting your Pull Request -- thank you.

• [✓] I have read the contributing guide lines at https://docs.suricata.io/en/latest/devguide/codebase/contributing/contribution-process.html
• [✓] I have signed the Open Information Security Foundation contribution agreement at https://suricata.io/about/contribution-agreement/
• [✓] I have updated the user guide (in doc/userguide/) to reflect the changes made (if applicable)

Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/6260

Describe changes:
Add config (decoder.recursion-level.use-for-tracking) to control the use of packet recursion level in flow matching. This is to support scenarios where Suricata inline IPS device is routing traffic over a non-encrypted tunnel, like IPv6 tunnels, packets in a flow will be dropped and not be matched. e.g.

The following example is a Suricata inline IPS with an IPv6 tunnel:
request: IPv4]ICMP] -> |IPS| -> IPv6]IPv4]ICMP]
reply: <- |IPS| <- IPv6]IPv4]ICMP]

Both the IPv4 request and IPv6 reply will be seen by Suricata on ingress. The flows will not be matched due to flow recursion level.

Provide values to any of the below to override the defaults.

To use a pull request use a branch name like pr/N where N is the
pull request number.

Alternatively, SV_BRANCH may also be a link to an
OISF/suricata-verify pull-request.

OISF/suricata-verify#1373

SV_BRANCH=pr/1373

[codecov]

Codecov Report

Merging #9464 (cd57c26) into master (2b57179) will decrease coverage by 0.02%.
The diff coverage is 73.91%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9464      +/-   ##
==========================================
- Coverage   82.18%   82.17%   -0.02%     
==========================================
  Files         968      968              
  Lines      274199   274207       +8     
==========================================
- Hits       225363   225322      -41     
- Misses      48836    48885      +49     

Flag	Coverage Δ
fuzzcorpus	64.10% <65.21%> (+<0.01%)	⬆️
suricata-verify	60.89% <73.91%> (-0.02%)	⬇️
unittests	62.88% <26.08%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

📢 Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=OISF).

[jasonish]

Can you explain this deployment scenario a little more? Does this happen with NFQUEUE and a rule like iptables -I FORWARD -j NFQUEUE when the same machine is doing to the tunneling/detunneling of said traffic? I just find it interesting that its not hooking in at the same level of tunnel.

[coledishington]

Can you explain this deployment scenario a little more? Does this happen with NFQUEUE and a rule like iptables -I FORWARD -j NFQUEUE when the same machine is doing to the tunneling/detunneling of said traffic? I just find it interesting that its not hooking in at the same level of tunnel.

I have confirmed this behavior in a deployment where packet pickup is performed by netmap on eth interfaces. I suspect that the suggested iptables rule would not have the same behavior since the routing decision has already been made for the packet and thus the tunnel headers could already be added for the ingress traffic.

[coledishington]

Rebased in #10214.