Re: [PATCH v3] netfilter: nf_conntrack: Add conntrack helper for ESP/IPsec

[Florian Westphal]

Cole Dishington <Cole.Dishington@xxxxxxxxxxxxxxxxxxx> wrote:
> +/* esp hdr info to tuple */
> +bool esp_pkt_to_tuple(const struct sk_buff *skb, unsigned int dataoff,
> +		      struct net *net, struct nf_conntrack_tuple *tuple)
> +{
[..]

> +	tuple->dst.u.esp.id = esp_entry->esp_id;
> +	tuple->src.u.esp.id = esp_entry->esp_id;
> +	return true;
> +}

Did not consider this before, and doesn't matter if we'd follow this
approach or expectation-based solution:

Do we need to be mindful about hole-punching?

The above will automatically treat the incoming (never-seen-before)
ESP packet as being part of the outgoing one, i.e. this will match
ESTABLISHED rule, not NEW.

With expectation based approach, this will auto-match a RELATED rule.

With normal expectations as used by helpers (ftp, sip and so on),
we nowadays don't do such auto-accept schemes anymore but instead
require explicit configuation, e.g. something like

iptables -t raw -p tcp -A PREROUTING -s $allowed  -d $ftpserver -j CT --helper "ftp"

... to make it explicit that the kernel may automatically permit
incoming connection requests to $allowed from $ftpserver.

Do we need to worry about this for ESP too?

If the expectation-based route is taken, another patch could be piled on
top that adds a fake ESP helper, whose only function is to let
esp_pkt_to_tuple() check if the 'outgoing/seen-before' ESP connection
has been configured with the "esp" helper, and then allow the expectation
(or, not allow it in case the existing esp ct doesn't have the esp helper).