struct flow_entry should have a single state: GK_BPF

[AltraMayor]

The states of a flow entry are enum { GK_REQUEST, GK_GRANTED, GK_DECLINED, GK_BPF }.

The states GK_GRANTED and GK_DECLINED have long been implemented as BPF programs, so their removal should not affect anyone. The downside of no longer having a way to compare the performance between built-in programs (i.e., the states GK_GRANTED and GK_DECLINED) and BPF programs is okay since that dropping the code associated with these deprecated states translates into a cleanup of the code of GK blocks.

Moving the state GK_REQUEST into a BPF program requires an extension of the running environment of the BPF programs. For example, the request BPF will need a way to update the expiration of flow entries and a mechanism to send packets to SOL blocks. A positive side effect of having a request BPF is to lower the effort to explore new strategies to prioritize undecided flows.

This streamline of struct flow_entry would be a preparation to integrate with future SmartNICs that support running BPF programs.

[AltraMayor]

Once states the states GK_GRANTED and GK_DECLINED are gone, the format of the policy decisions should be simplified since the decision types GGU_DEC_IPV4_DECLINED, GGU_DEC_IPV6_DECLINED, GGU_DEC_IPV6_GRANTED, and GGU_DEC_IPV6_GRANTED can go away as well.

In order to have an incremental upgrade path, new Gatekeeper servers must support the old protocol and the new protocol, while new Grantor servers only speak the new protocol. Thus, the upgrade path consists of upgrading the Gatekeeper servers, then the Grantor servers. Finally, the old protocol can be dropped in the following release of Gatekeeper.

[AltraMayor]

Once request BPF programs become an option, one could write a port-knocking request BPF that only forward a request to Grantor servers after the knocking has been done. On one hand, this new request BPF would only be viable for things like APIs since they can require applications to change. On the other hand, this new request BPF would be extremely effective against all types of attacks since it would filter out all non-authenticated flows from issuing a request to Grantor servers.

In addition, port knocking could be implemented by verifying a cryptographic key instead of just carrying a secret. For example, APIs could require their applications to present a signed certificate that expires for port knocking.

With the proliferation of request BPF programs, there will be a need to support multiple request BPF programs on a single Gatekeeper server. This could be done by adding the index of the request BPF program to FIB entries (i.e. struct gk_fib), so Gatekeeper servers can identify which request BPF program to apply to a new flow.

Finally, a new parameter in struct gk_config is required to identify the default request BPF program when none is specified in a FIB entry. Name suggestion for this parameter: default_request_bpf.