Log packets going through a rule

[qdeslandes]

Introduce a new keyword to log a packet when a rule is matched. This could be used for audit or debug purposes: the user could retrieve information about the packets matched by a specific rule.

A bpfilter rule can match any packet, so it's not possible to know in advance which protocol headers will be available in the packet. Furthermore, the user might want to log a header that is not matched by the rule (e.g. log the layer 2 header (IPv4 or IPv6) for every TCP packet). Hence, the log keyword should be followed by the protocol layers to log (l2, l3, ...).

bpf_printk() is too slow to log packets at line rate, but the BPF program can log the requested data into a ring buffer, which could be fetched from user-space by the user directly or through bfcli/bpfilter.

This new keyword should be used similarly to the counter keyword:

rule
    ip4.addr eq 192.168.1.1
    counter
    log l2 l3
    ACCEPT

Previous issue details (out of date)

[`nftables`](https://wiki.nftables.org/wiki-nftables/index.php/Logging_traffic) allows for packets to be logged: if a packet matches the rule's criteria (some of) its content is logged.

The exact implementation is not defined yet, as there are multiple questions that should first be answered:

• Should this be a new verdict? A rule should be able to log a packet and then apply a verdict (accept, drop, ...). If we define a new LOG verdict, it mean we should allow for verdicts to be combined such as LOG | DROP. Otherwise, it could be a rule directive like counter is in bfcli.
• How to actually log the data? bpf_printk() is too slow and not meant for this, BPF perfbuf could be used, but it BPF ringbuf could be better.
• What should be logged? Having the user define specific fields to log would complexify the bytecode: we would have to first check if the field is available in the current packet and then copy only the required data. Another approach could be to copy part of the program's runtime context back to userspace which contains: L3/4 protocol, L2 header, L3 header, L4 header. The user could also request only specific headers.