Keep Track of Dynamic TCP Sessions to Allow Better Scoped Network Policy

[mike-carrigan24]

Describe the problem/challenge you have
Certain TCP protocols (ex. FTP, SFTP, NFSv3) use dynamic ports for certain services (NFSv3 for example uses them for NLM, MNT, and STATD). These are necessary for these protocols to operate properly. Due to the dynamic nature of these ports, scoping Network Policy to allow these protocols is difficult. Accounting for dynamic ports often requries provisioning all TCP highports or, in some instances, all TCP ports. This requires Network Policies to be provisioned with a significantly wider scope than would be desired.

Describe the solution you'd like
Ideally, when a dynamic session is stood up as a result of one of these protocols, this session is evaluated with respect to the protocol that spawned it instead of being evaluated as a new session. This would allow Network Policy for these protocols to be better scoped and easier to manage.

Anything else you would like to add?
While these protocols sometimes have the ability to set a specific port range for dynamic services, they can be difficult to configure, especially at scale.

Also, I believe Open vSwitch connection tracking has the ability to do this with the "ct_tp_dst" field, however I am not super familiar with it so I may be mistaken.

[antoninbas]

Thanks for submitting this.
My understanding is that the recommendation when using NFSv3 with a firewall (which would include Antrea NetworkPolicy implementation) is to assign static ports for these services which use dynamic ports by default?

Ideally, when a dynamic session is stood up as a result of one of these protocols, this session is evaluated with respect to the protocol that spawned it instead of being evaluated as a new session.

I believe that ports are allocated and "distributed" out-of-band by something called rpcbind? This happens at the app layer, not at the transport layer. As a result, Antrea would have no knowledge of which port have been assigned for the dynamic NFS services. The only way to know them would be to intercept these packets, parse them and extract that information. In. other words, from the perspective of Antrea / OVS / conntrack, there is nothing that ties the new sessions (for NLM, MNT, and STATD) to your original NFS session (presumably using port 2049) or RPC session (presumably using port 111).

ct_tp_dst is the original destination port prior to NAT being performed. For example, when you access a K8s Service using the ClusterIP and Service port, ct_tp_dst will "preserve" the value of the original Service port, while the destination port in the packet is rewritten (DNAT) to the target port (i.e. port on which the Pod Endpoints are listening). We are still talking about the same connection here, not a separate but "related" connection (again, "related" here is application-specific - in this case, NFS-specific).

I know that Suricata has some support for NFS, so a L7NetworkPolicy may be an option here (we would need to add support for NFS). But I don't know the extent of that support, nor how the individual services are handled. I believe that NFSv3 is quite ancient as well, and that NFSv4 is recommended?

My take is pretty much the same for FTP. Note that passive FTP was listed as one of the motivating use cases for port range support in K8s NetworkPolicies: https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/2079-network-policy-port-range/README.md#story-3---containerized-passive-ftp-server. Here as well, we could add FTP support to L7NetworkPolicy given that Suricata supports it.