L7 NetworkPolicy cannot allow HTTP request data larger than MTU

[hongliangl]

Describe the bug

This is a simple L7 NetworkPolicy to allow URI /echo with parameters:

metadata:
  name: egress-allow-http
spec:
  priority: 5
  tier: application
  appliedTo:
    - podSelector:
        matchLabels:
          app: busybox
  egress:
    - name: allow-http
      action: Allow
      l7Protocols:
        - http:
            method: "GET"
            path: "/echo*"
    - name: drop-other
      action: Drop

After we apply the policy, the corresponding Suricata rules are:

# Reject non-allowed traffic
reject http any any -> any any (msg: "Reject by AntreaNetworkPolicy:default/egress-allow-http"; flow: to_server, established; sid: 1;)
# Allow HTTP GET requests to the /echo endpoint
pass http any any -> any any (msg: "Allow HTTP by AntreaNetworkPolicy:default/egress-allow-http"; http.uri; content:"/echo"; startswith; http.method; content:"GET"; sid: 2;)

In a busybox Pod to which the policy is applied, we test the policy with following cases:

• Case 1:
  • Command: curl http://192.168.77.101/echo?msg=$(head -c 2000 </dev/zero | tr '\0' 'A')
  • Description: The HTTP payload is split across multiple packets due to its size.
• Case 2:
  • Command: curl http://192.168.77.101/echo?msg=$(head -c 100 </dev/zero | tr '\0' 'A')
  • Description: The HTTP payload fits within a single packet.
• Case 3:
  • Command: curl http://192.168.77.101/hostname
  • Description: A request to an endpoint not allowed by the policy (e.g., /hostname).
• Case 4:
  • Description: Traffic using other L7 protocols (e.g., TCP, UDP, or ICMP).

Expected behavior

• Cases 1, 2: Allowed, as they match the policy permitting HTTP GET requests to /echo.
• Cases 3, 4: Rejected, as they do not match the allowed policy.

Observed Behavior

• Cases 2-4: Behave as expected.
• Case 1: Fails unexpectedly. When the HTTP payload is split across multiple packets, the first packet containing part of the HTTP data matches the reject rule (SID: 1). This prematurely interrupts the connection, even though the request aligns with the policy.

How to debug manually

To troubleshoot the Suricata rules for cases 1-4, I followed these steps:

1. Access the Antrea agent shell using:

   kubectl exec -it -n kube-system antrea-agent-xxxx -- bash

2. Edit the rule file (e.g., /etc/suricata/rules/antrea-l7-networkpolicy-2.rules) using vi or vim.
3. Reload Suricata tenants to apply the updated rules:

   suricatasc -c 'reload-tenants'

4. Test cases 1-4 directly from the BusyBox Pod.

Misc

I made an issue https://redmine.openinfosecfoundation.org/issues/7457?issue_count=6&issue_position=1&next_issue_id=7340 to Suricata community for help and hope we can get some guidance from there.

cc @antoninbas @tnqn