The basics of connection tracking and offload

In this blog, i will explain the basics of connection tracking in form of FAQs.

A. Connection tracking maintains the state of the connection? Ok, What does it mean? 

There are lots of packets coming-in and going-out of a system connected to the network. Admin knows that. But what if he wants to know where all those packets are coming from and going to? Are there packets just coming in and there is no response to it? Is there a packet just going out But no response back? What if Admin wants to know the associations of packets with Layer 4 ports and services running inside the system? And finally, What is the state of those service’s networking state? Answer to all these questions is Connection tracking. 

B. So, What are those services whose state can be maintained by a connection tracking module? 

Connection tracking modules can look into TCP, UDP, ICMP, DCCP, SCTP, GRE protocols headers. So, any services using one of these layer 4 protocols can be maintained by connection tracking. I.e HTTP uses TCP so connection tracking can maintain any HTTP session opened in the system. 

C. Alright, so I could see ESTABLISHED in the connection tracking table? What is next? 

Connection tracking at host level gives more control to Infra Admin on affairs of services. Admin can manage the sessions with timeouts, counts, rejection, statistics etc. Via its APIs, those can be used by SDN controller/Firewall application as well.   

D. Ok, Why does the SDN environment need connection tracking? If it is just a matter of tracking the session state from the packets? Can’t SDN controllers do it?

Technically, an SDN controller can do it. It’s just more code writing required in the controller. However, linux kernel’s connection tracking module does the same job, so why write something new? 

Look below, 

nf_nat                 45056  2 ipt_MASQUERADE,nft_chain_nat

nf_conntrack          172032  4 xt_conntrack,nf_nat,xt_state,ipt_MASQUERADE

RHEL uses a netfilter framework to implement networking plumbing in the system. Though connection tracking code/module can be used by BPF based implementation as well. So, the answer is when you have a state maintaining tool (That can look deep into the protocols headers of the packet), it is a wise idea to use it. 

You can see in the output capture that nf_conntrack is used by nf_nat as well. 

E. So, What are the use cases of connection tracking?

There are many like NAT, Layer 4 to Layer 7 services, Helps in DoS attack prevention, Per session ACLs etc. 

F. I do see ct_zone, ct_flags, ct_labels, ct_states in the flow? What are those and Who writes its values in the flow? 

A service can have multiple sessions, ct_zone,ct_label,ct_mark,ct_flags can be used to identify/track sessions of the service so each can be treated differently and acted upon. These ct_X are programmed by the SDN controller/Firewall who is using the CT module present in the host system. Ct_states helps in identifying the state of the session like ESTABLISHED, INVALID etc.

G. Finally, how offload of these sessions happen with ovs hw offload?

Let’s look at the packet lifecycle now. 

Packet lifecycle:

TCP session requires 3 way handshake But for simple explanation i will use SYN, ACK only. VF is inside the VM and application running on top of it.

Incoming TCP SYN:

Outgoing ACK:

Once session is offload, we could see below entry in connection tracking table.

ipv4 2 tcp 6 src=10.10.54.100 dst=7.7.7.68 sport=32768 dport=22 src=7.7.7.68 dst=10.10.54.100 sport=22 dport=32768 [HW_OFFLOAD] mark=0 secctx=system_u:object_r:unlabeled_t:s0 zone=9 use=1225520

To summary, connection tracking is the state maintainer and perform the action as being told on the session it is tracking. Commercial firewalls too use linux kernel CT module and adds their use space features(thus called state full) on top of it.

Hope, this blog helped to clear some of basic doubts on connection tracking and offload.