Cole Dishington Cole.Dishington@alliedtelesis.co.nz 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).