Fix default reject rule to correctly handle packets that should be assembled

[hongliangl]

When using an L7 NetworkPolicy that allows egress HTTP requests, the corresponding Suricata rules may look like the following example:

reject ip any any -> any any (msg: "Reject by AntreaNetworkPolicy:default/egress-allow-http"; flow: to_server, established; sid: 1;)
pass http any any -> any any (msg: "Allow http by AntreaNetworkPolicy:default/egress-allow-http"; http.method; content:"GET"; sid: 2;)`

If an HTTP request exceeds the MTU, it will be split into multiple packets. The packets should be reassembled and allowed by the corresponding Suricata rule for the L7 NetworkPolicy.

However, there is a default reject rule which is to reject packets which are not matched by the pass rule, which will take effect before packets are reassembled and matched by the pass rule, causing the connection to fail.

To address the issue, the keyword only_stream is added to the default reject rule. This ensures that only reassembled packets are matched, preventing premature rejection of packets that should be allowed after reassembly.

[tnqn]

Great finding.

But does it fix a new issue or #6806?

[antoninbas]

I have read about the only_stream keyword previously, but had trouble understanding how it works. Other people also seem to find the behavior surprising: https://forum.suricata.io/t/rule-with-flow-option-only-stream-never-seems-to-match-anything/1655

We definitely need to test the case where request packets (to_server) exceed the MTU, with a new e2e test. The e2e tests are currently failing with this change:

--- FAIL: TestL7NetworkPolicy (143.42s)
    --- FAIL: TestL7NetworkPolicy/HTTP (50.38s)
        --- FAIL: TestL7NetworkPolicy/HTTP/Ingress (22.19s)
        --- FAIL: TestL7NetworkPolicy/HTTP/Egress (22.18s)
    --- FAIL: TestL7NetworkPolicy/TLS (18.16s)
    --- FAIL: TestL7NetworkPolicy/Logging (45.23s)

BTW, I have found that testing Suricata rules is much more convenient when using a pcap file and running Suricata in offline mode. While we still need e2e tests, I wonder if we could have some extra tests (maybe with input pcap and expected JSON logs) to quickly evaluate our Suricata rules. Maybe the best approach would be to have a separate repo where we can keep some reference pcaps that people can use when working on L7NP (bug fixing, support for new protocols, etc.). What do you think @tnqn @hongliangl?

[antoninbas]

Great finding.

But does it fix a new issue or #6806?

I don't know if the current patch is correct because tests are failing.
I think the issue may be orthogonal - but related - to #6806. #6806 was for reply packets coming from the external packet. This fix is for packets in the other direction (which match the to_server keyword). Both fixes are going to be needed. This fix is about handling app requests that span multiple packets, but we still need to handle checksum issues for reply traffic (#6806, and its proposed fix #6843).