Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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...).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
