On 26.11, Pablo Neira Ayuso wrote: > On Thu, Nov 26, 2015 at 04:07:26PM +0100, Florian Westphal wrote: > > I would prefer to NOT force people to use extra connection tracking code > > for sctp if they don't need it. > > > > Most distributions will ship with all of this as '=m', but IMHO its safe > > to assume that most users will in fact not use sctp (but conntrack for > > udp and tcp). > > Enabling features through modprobe seems not to be a good idea > anymore, now we've got namespaces. Good point. In fact I never liked that fact that using a module on the host automatically makes it available to all namespaces. > We should probably go back to the idea of explicit conntrack > configuration through rules that we discussed many times before. I don't think that would solve the problem. Consider: -i eth0 -j CT --track -i eth0 -p sctp --dport 1234 -j ACCEPT -i eth0 -m state --state ESTABLISHED -j ACCEPT The explicit tracking rule *still* has no knowledge that the SCTP module is required. Depending on how the rule is built, there's no difference to automatic tracking since it might simply be a catch all rule. Sure, you could require users to enable it manually for each and every protocol, but I expect we agree that this is not a very nice way. What we have to do is: *If* we're using stateful tracking, *and* it is possible that connection state is based on a user selected connection identity (by using the protocol specific matches), then we have to enable connection tracking for that protocol to make sure we don't mix up connections with different identities. How we enable it is an entirely different question, but it needs to be done to fullfil what I think is a reasonable expectation of stateful filtering. -- 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
