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

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, Oct 19, 2016 at 02:57:33PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
[...]
> > > 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.

At quick glance, udplite is a copy and paste from udp trackers, except
for the udplite_error() function. So glad to see this merged into UDP.

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

Actually, this would add a dependency for nf_nat, not for
nf_conntrack. The real crc32c implementation details are placed
behind the crypto infrastructure, I don't see any way we can skip
this.

We can still keep config NF_NAT_PROTO_SCTP around, just turn it into
boolean toggle, so people can still compile this out if such
dependency becomes a problem.

I would also remove 'default IP_SCTP' from CONFIG_NF_CT_PROTO_SCTP
since we don't need any local SCTP stack support to forward packets.

Just to summarize: What we're discuss here is a good default
configuration. After reading those RFCs that propose SCTP over UDP
tunneling tricks to workaround firewalls on the Internet, my
impression is that we may be probably responsible for this in some
way.

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

Correct, it's fairly small amount of code.