Re: [PATCH nf-next 0/2] netfilter: autoload NAT support for non-builtin L4 protocols

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Tue, Oct 18, 2016 at 11:12:42AM +0200, Davide Caratti wrote:
> [...]
> > > Once these protocols are supported built-in, users can configure from
> > > our control plane, ie. iptables/nft, if they explicitly don't want to
> > > allow them by dropping protocols of this kind. But in that case we
> > > would not be responsible anymore for the current situation at least.
> > > 
> > > Moreover, following this approach, we would also avoid the new
> > > attribute in nft_nat to indicate the layer 4 protocol that you have
> > > mentioned already.
> > 
> > Ok - so do you think it's better to have
> > nf_nat_proto_{dccp,sctp,udplite}.o built into nf_nat.ko and
> > nf_conntrack_proto_{dccp,sctp,udplite}.o,
> 
> Yes. We agreed on doing so during the Netfilter Workshop Amsterdam.

Hmm, did we?  I wonder what my opinion on that subject was :)

> > and maybe also nf_conntrack_proto_gre.o, built into
> > nf_conntrack.ko? 
> 
> Please, keep gre back by now, I think this is quite specific of the
> pptp conntrack helper that we have in the tree and it only works for
> IPv4 and it cannot work with NAT either, it's very limited. So please
> start by building in dccp, sctp and udplite protocols.

Wrt. udplite, I think it makes sense to merge it into udp one, I suspect
a lot of this becomes redundant after some refactoring.

For sctp I am not so sure, it will add a dependency of conntrack
on crc32, but maybe thats not so important...?

Merging NAT makes sense, the external helper modules are very
small (~120 lines inlcuding boilerplate...).