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.
> 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.
Thanks.
--
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
